<uvos>
Wizzup: i dont like autotools because of the somewhat insane layering going on with tools writing files for tools. Im fine with using some other build system and rebasing my stuff on that as long as the following is met:
<uvos>
1. the build system links the modules sanly instead of staticly to half of mce and to every dependancy
<uvos>
2. the buildsystem knows how to build only the modules that have all the dependancies available
<uvos>
if you do that for autotools im fine with it
<uvos>
also 3. we should migrate mce from -rdynamic to --dynamic-list and -flto
<uvos>
together this saves like 4mb ram
<uvos>
witch is very relevant on n900
ravelo has quit [Quit: Connection closed for inactivity]
<Wizzup>
uvos: ok, great points
diejuse1 has joined #maemo-leste
<Wizzup>
uvos: I will try to see if I can do that with autotools, but otherwise, we can consider moving to cmake I think
<Wizzup>
uvos: If those flags help that much mce, they might also with our other daemons?
<parazyd>
fwiw cmake also works magically with debhelper
<parazyd>
No changes needed there
<uvos>
Wizzup: its just a particularity with mce's modularity
<uvos>
Wizzup: they ensured that all symbols are available by staticly linking every module with all of mce
<Wizzup>
uvos: I just realised we are going from make to cmake, I think that's ok, for some reason my head thought we were going from automake to make
<Wizzup>
uvos: hmhm, ok
<uvos>
so every module is 150kb in size
<uvos>
times like 30
<uvos>
instead with the above flags we can define a real plugin interface
<Wizzup>
mhm
<parazyd>
Good points
<uvos>
Wizzup: ok
<uvos>
Wizzup: whatever you choose
<uvos>
Wizzup: the prs that are still based on top of plain makefile mce need to be looked at first
<parazyd>
Yeah we should go with that one by one
<parazyd>
There are 8 prs now
<uvos>
right those 8 are everything i did before swtiching to cmake
<Wizzup>
should we perhaps define some test of 'application tests' to make sure the maemo interfaces don't break with this stuff, or some other way to keep track of the interfacew changes, if any?
<uvos>
some tests would be good ofc
<uvos>
but the prs dont change any external interfaces
<uvos>
later (after cmake) some external interfaces change in the name of de-gconfing stuff
<uvos>
also all the gconf interfaces are gohne if you dont load rtconf-gconf, but that should be obvious
<Wizzup>
mhm
<uvos>
another small thing i wanted to discuss regarding mce is:
<uvos>
i would like to ammend the $(Device).ini files in leste-config to configure the power button to lock the device and a long press on the power button to show the power menu. instead of the current default behavior of short press = power menu and long press = poweroff.
<uvos>
as i think having no quick way to lock the device on devices wihout a lock slider is not great
<uvos>
ie everything execpt n900
<parazyd>
You press it twice fast to lock
<uvos>
true that works i just find it kinda annying since you have to do it so often
<uvos>
parazyd: so you use defaults?
<Wizzup>
uvos: I think if we do it for the mapphone, it is not such a big deal, it'
<Wizzup>
it'd be a bit confusing I think
<Wizzup>
but I also see how it can make more sense
<Wizzup>
uvos: btw, on all the mce work and stuff, I think it'd be cool if you can describe/document how you use leste and what parts you swapped out
<Wizzup>
I think others would like to see e.g. the modularity, and how you swap out the lock screen, other parts
<uvos>
Wizzup: sure
<uvos>
Wizzup: altho i mostly use leste as is on one device and plain debian with i3 and mce and no other leste parts on the other.
<uvos>
Wizzup: on leste i mainly just dont use tklock
<Wizzup>
ok, well, I think it'd still be interesting
<uvos>
yeah i can write something up about replacing tklock with another lock screen
<parazyd>
uvos: Yes @ default
<uvos>
parazyd: ok
<uvos>
ok i think i will just keep default as is for now (power button behavior)
<Wizzup>
I do use the lock feature a lot more than the power menu
<Wizzup>
but yeah, agreed
<uvos>
maybe we can discribe how the power button works in the greeter, that i just finished btw pushing.
<uvos>
as people will expect it to work like in android and ios
<Entitlement>
parazyd - [ Sxmo: Simple X Mobile - A minimalist environment for Linux smartphones - Diode Z... ]
<sicelo>
Ah yes, yesterday at alpineconf. I watched it
<uvos>
honestly, that looks extreamly painfull to use on a ts only device
<sicelo>
You'll be surprised
<sicelo>
They really did intelligent stuff with the gestures
<sicelo>
After all, it's only target is PP
<uvos>
yeah but no matter what you do with gestures using terminal applications requires a lot of text input
<uvos>
anyhow i should maybe try it
<sicelo>
And?
<uvos>
and text input is painfull on a vkb
<uvos>
especcaly text input you cant autocorrect
<uvos>
becuase its not workds
<uvos>
*words
<sicelo>
Well
<freemangordon>
Hi! Did I miss something in the meanwhile?
<Wizzup>
freemangordon: hi
<Wizzup>
welcome back
pagurus has joined #maemo-leste
belcher has quit [Ping timeout: 268 seconds]
belcher has joined #maemo-leste
ravelo has joined #maemo-leste
mepy has joined #maemo-leste
mepy has left #maemo-leste [#maemo-leste]
jonsger has joined #maemo-leste
VulcanRidr has quit [Ping timeout: 246 seconds]
diejuse1 has joined #maemo-leste
inky has quit [Ping timeout: 260 seconds]
inky has joined #maemo-leste
VulcanRidr has joined #maemo-leste
<inky>
parazyd: very interesting video. thank you for sharing!
<uvos>
would be great if someone would to that kind of tour video for leste
<uvos>
maybe once a year or so
<Wizzup>
yeah
<uvos>
*make
<uvos>
Wizzup: any progress on sdl?
<Wizzup>
uvos: not yet, was working on some icd2 thing
<Wizzup>
uvos: still not quite sure how to approach this
<Wizzup>
freemangordon: any objections to switching mce to cmake (from plain make), given that uvos already did the work and doesn't know how to do it in autotools?
<Wizzup>
freemangordon: I think it makes sense, given that uvos is basically doing most of the mce work
<Wizzup>
uvos: I guess getting rid of some maemo patches makes sense, but there is also the window misplacement that I don't get
<uvos>
Wizzup: that happens in plain git sdl 1.2?
<Wizzup>
uvos: that I will have to check
<uvos>
Wizzup: dont worry im compiling that rn on d4
<uvos>
will take some time
<Wizzup>
ok, one thing from uvos changes stood out to me, and that was the XCreateWindow change
<uvos>
are the mameo patches strictly nessecary for meamo sdl apps?
<uvos>
as in do they provide features
<uvos>
or just workarounds for hildon bugs
<Wizzup>
uvos: sorry, I mixed up the names
<Wizzup>
I meant clort
<Wizzup>
but I think typically x and y should be 0 there
<Wizzup>
unless xinerama has multiple windows
<Wizzup>
uvos: I think they're mostly workarounds for bugs in h-d
<uvos>
Wizzup: those values should not matter
<Wizzup>
I think one of them is to make the volume control work when input is grabbed, though
<uvos>
unless the window is override redirect
<uvos>
witch it is in sdl 1.2 afaik
<Wizzup>
That is debian/patches/320_no_fullscreen_grab.diff
<Wizzup>
(volume grab)
<Wizzup>
uvos: the maemo patch disables override redirect in fullscreen I think
<Wizzup>
that is debian/patches/340_fs_notor.diff
jonsger has quit [Ping timeout: 252 seconds]
<uvos>
git sdl1.2 has the same offset isue
<uvos>
also it holds a exclusive keyboard grab
<uvos>
but cloudgps gets no keyboard input
<uvos>
witch is a real headscratcer
<Wizzup>
uvos: yes, I think this is perhaps with the wrong window getting the input
<Wizzup>
is that in fullscreen btw?
<uvos>
cloudgps only has one window
<uvos>
yes fullscren
<Wizzup>
what does xwininfo -tree say?
<uvos>
cloudgps has only one window where it sets NET_WM_PID to itself at least
<Wizzup>
It might have one window in h-d but there are definitely several X windows
<uvos>
there is only one xwindow it claims via NET_WM_PID
<uvos>
ill install xwininfo sec
<Wizzup>
freemangordon: I'm looking at the icd2 service providers things, and I couldn't find anything that actually used it, but there are some references to it in connui - do you know of any actual icd2 provider thing, or shall I just make a stub based on the api?
<uvos>
Wizzup: 0 children.
<uvos>
Wizzup: the window that cloudgps claims via NET_WM_PID has no children
<inky>
what is mce?
<uvos>
inky: a program that dose some hardware abstraction for leste
<inky>
okay. (:
<uvos>
inky: "mode controll entitiy" but thats a artifact title as it controles no modes really
<Wizzup>
uvos: hmm
<uvos>
Wizzup: so in the sdl1.2 test suite
<uvos>
input works perfectly fine both kbd and mouse
<uvos>
in all test programs
<uvos>
in fullscreen and in windowed mode
<inky>
so it's sdl.
<inky>
i use maelstrom on leste.
<inky>
it uses sdl 1
<inky>
hope it'll work ok.
<Wizzup>
uvos: weird..
<Wizzup>
uvos: do the window properties look different?
<Wizzup>
at least in my case the mouse input was jerky/not-ok
<uvos>
Wizzup: where do you test mouse?
<uvos>
cloudgps seams to not react
<Wizzup>
I just drag around on the world map
<uvos>
but sdl test app shows touch inputs
<Wizzup>
if you see only gray, remove the cloudgps cache or something, since it goes out of earth bounds
<uvos>
i dont think it works
<uvos>
im not sure what sdl1.2's testcursor app is supposed to do
<uvos>
but its not doing anything on touch
<uvos>
sec
<uvos>
no its fine
<uvos>
it gets the right mouse coordinates
<uvos>
just shifted
<uvos>
like the window
<uvos>
i think the shift is the only problem
<Wizzup>
maybe, but when I disabled some patches the mouse scrolling was kinetic, and without it, I don't think it was, it just jumped
<madfitter>
Hey all! So, I'm new to Maemo, and new to the Pinephone.....however I am not new to linux ar to flashing hardware. I'm currently flashing this build to my pinephone (Looks like it's setting the file system up via script). So, how's everything progressing? Anything I can do as far as testing/helping? I do have some compiling experience with android
<Wizzup>
but maybe the window offset should be fixed first
<madfitter>
and some general linuxstuff.
<uvos>
Wizzup: where is cloudgps cache?
<uvos>
Wizzup: its all gray now
<Wizzup>
uvos: I think ~/.cloudgps, or maybe ~/.cache/cloudgps or so
<Wizzup>
madfitter: hi, welcome :)
<uvos>
Wizzup: its perfectly fine
<uvos>
in portrait mode
<uvos>
where its not shifted i scrolls as you would expect
<madfitter>
Wizzup hello. So it looks like Maemo has a pretty lengthy history.
<Wizzup>
uvos: maybe the window shift comes from rotation and some w/h being swapped
<Wizzup>
madfitter: that's for sure, first linux based smartphone in 2009 or so :)
<uvos>
Wizzup: the mouse only works in a 640x480 window
<Wizzup>
uvos: ?
<uvos>
in cloudgps it only gets events inside of the default 640x480 sdl surface
<Wizzup>
madfitter: we're based on devuan (debian without systemd), and run X11 and generally try to be a mobile linux phone, but many desktop apps might work
<uvos>
same with sdl1.2 testwm
<Wizzup>
madfitter: I think some challenges on the pinephone are keyboard input in frameworks where we do not yet have virtual keyboard-raise support
<Wizzup>
uvos: odd
<uvos>
Wizzup: its just reading the xdisplay size wrong
<uvos>
thats all there is to it
<uvos>
now why
<Wizzup>
madfitter: in general, I'd suggest you see how well or poorly it works for you, and start there. 3d graphics is better in portrait mode
<Wizzup>
madfitter: maemo was designed for a device with a hardware keyboard, so a device without a keyboard still has some usability issues atm
<uvos>
keyboard should raise work with vol up on pp on any window btw
<uvos>
in devel only maybe
<madfitter>
Wizzup Gotcha. I wonder how well the work on the physical keyboard is going, as it may make life easier for you. But anyway, yes, I'm going to boot it up and play with it. If I like what I see (love the available photos and screenshots), I'll start looking into code.
<Wizzup>
uvos: cool, I didn't try that yet
<Wizzup>
madfitter: great, let us know also if you don't like what you see, so we know what to work on
<Wizzup>
for the pinephone, 3d is one of the things that bugs me (landscape is slow), and it's a bit buggy - it's a driver thing
<Wizzup>
and in case you didn't realise yet, we don't have a phone call gui yet/atm
<madfitter>
Wizzup Will do! That's fine. I haven't even dropped a sim card into it yet.
<Wizzup>
check, I have a pinephone here in case there's some bug and you'd like me to repro or so
<inky>
i wrote several things about pinephone, when was testing leste on friend's phone. exactly a week ago.
<inky>
let me try to find.
<inky>
someone, i guess uvos said it shouldn't be like that.
<madfitter>
I have been with android for years, but am sick of worrying about privacy concerns. Linux phone was the natural choice, but there's so many to chose from and at many different stages of development. And what can I say? I'm a sucker for a great UI/UX and something different :)
<inky>
also you were discussing here if people are used to android, so i am not.
<inky>
i used n900/maemo, then jolla/sailfish, now sailfish on xperia and leste.
<madfitter>
I flashed straight to the emmc, so does the file mounting script usually take a while?
<inky>
i also don't use sim card in phone, i have portable wifi access point.
<inky>
never use phone calls and sms, also because of privacy concerns.
<inky>
i have my jabber server and contacts in jabber.
<inky>
so i saw there is some work on new modest, and that is cool.
<inky>
i also hope we'll have jabber integrated with address book.
<inky>
now i use dino-im on leste.
<Wizzup>
inky: yes, we will @ address book and jabber, we definitely want that
<inky>
but my problem is armenian layout and my hope is uvos. (:
<uvos>
my hope on that is inky :P
<inky>
i mean that xorg doesn't see our leste keyboards.
<madfitter>
I'm booting and it's hanging on "crng init done"
<Wizzup>
it might take a bit, I don't know how it works with flashing to emmc to be honest
<inky>
well i gave you that source! (: i am waiting for you to generate some header file from it and use it instead of switch in your code. (:
<uvos>
inky: oh wait you where expecting me to generate a header from that?
<uvos>
i was hoping you would do the leg work on that one
<madfitter>
Wizzup Thanks. I'm patient :)
<inky>
i thought we came to that conclusion. (:
<Wizzup>
madfitter: otherwise try sd card first maybe
<uvos>
inky: ill eventually do it
<inky>
no problem, take your time!
<uvos>
inky: but if you have the time it would help immensly if you generate the header
<uvos>
inky: if you are so inclined
<madfitter>
Wizzup I'm going to try that now.
<inky>
uvos: ok! i'll ping you to agree which kind of format would you want me to get from that source.
xmn has quit [Read error: Connection reset by peer]
xmn has joined #maemo-leste
* Wizzup
zzz
<inky>
so i found pinephone issues: battery applet is not visible. screen is not rotating. my light meter doesn't find the device. cannot find the expected directory at /sysbus/iio. graphic redraws don't work well.
<uvos>
sysbus/iio is a nonstandard sysfs path
<uvos>
you have to use iio-sensor-proxy in your app via dbus now
<uvos>
or use /sys/bus/iio directly
<uvos>
but not reccomended
<uvos>
the sysbus/iio cant possibly work anywhere except the n900 and its vendor kernel
<uvos>
not sure about the other problems those should work
<uvos>
but we only have one dev with a pp n ow
<uvos>
(Wizzu)
<uvos>
*(Wizzup)
<inky>
no no it works on droid4 and i was sure it was a standard path. wait.
<uvos>
monitor-sensor is also installed on your device so you can check that the sensor works there
xmn has quit [Read error: Connection reset by peer]
<inky>
thanks will check tomorrow!
xmn has joined #maemo-leste
<uvos>
Wizzup: here is the problem
<uvos>
X11 detected Xinerama:
<uvos>
xinerama 0: 960x540+0+0
<uvos>
VidMode modes: (unsorted)
<uvos>
Mode 0: 540 x 960 @ 59
<uvos>
VidMode is enabled
<uvos>
X11 video mode list:
<uvos>
960x540
<uvos>
540x960
<uvos>
x y 0 0
<uvos>
thats sdl1.2
<uvos>
xinerama is working fine but sdl also checks with vidmode
<uvos>
and that only gives you the primary resolutions supported
<uvos>
because of randr rotation these are not the same
<uvos>
so sdl ends up terribly confused
ravelo has quit [Quit: Connection closed for inactivity]
<uvos>
its just sdl prefering xvidmode over xrandr
<uvos>
so it goes down a crusty code path that dosent understand rotated displays
<uvos>
you can force it to use legacy randr by compiling with "./configure --enable-video-x11-xrandr=yes --enable-video-x11-xinerama=no --enable-video-x11-vm=no --enable-dga=no --enable-video-x11-xv=no --enable-video-x11-dgamouse=no "
<uvos>
this fixes all isues
<uvos>
all the maemo patches are to work around the terrbly broken fullscreen and input handling that i fixed in hilodon recently
<uvos>
so with those flags stock sdl1.2 just works