| arno11 | freemangordon: the 4 pkg update from yesterday evening increase power consumption of 50mA | 14:03 |
|---|---|---|
| arno11 | I've triple checked and tested from fresh install twice | 14:04 |
| arno11 | otherwise idle is now 47mA with overclock :) | 14:05 |
| arno11 | and without the 4 pkg | 14:06 |
| arno11 | no more poweroff issue when disabling probs modules | 14:07 |
| arno11 | back in 2 hours | 14:09 |
| freemangordon | hmm, I saw similar on d4 | 14:35 |
| freemangordon | (increased power usage) | 14:35 |
| freemangordon | will try to downgrade Xorg | 14:36 |
| Wizzup | maybe noise on dbus? | 14:53 |
| Wizzup | not sure how xorg can cause it | 14:53 |
| freemangordon | but why? | 14:53 |
| freemangordon | see https://pastebin.com/9xzCQxbL | 14:54 |
| Wizzup | maybe X has access to more/less and does more/less? no idea... | 14:55 |
| Wizzup | maybe compare X logs or something | 14:56 |
| Wizzup | or maybe still some profile sourcing thing | 14:56 |
| Wizzup | (not sure) | 14:56 |
| freemangordon | profile is sourced correctly | 14:56 |
| freemangordon | will try to start xorg as root | 14:56 |
| freemangordon | to see if it will make any difference | 14:56 |
| sicelo | 47mA? wow! | 14:57 |
| sicelo | sounds news-post-worthy ... tmo people would love to hear such news. may generate a bit more interest in Leste too | 14:58 |
| Wizzup | it is, but it is not yet in any leste-config pkg | 14:58 |
| Wizzup | :) | 14:58 |
| freemangordon | Wizzup: confirmed, it is xorg running as user :( | 15:06 |
| freemangordon | https://pastebin.com/9AGnBne0 | 15:07 |
| Wizzup | huh | 15:09 |
| Wizzup | maybe check if xorg has additional fds open or something | 15:09 |
| Wizzup | or maybe check if their env is different | 15:09 |
| Wizzup | I feel like this might be some pvr option not being read | 15:09 |
| Wizzup | maybe pvr xorg cannot read /etc/powervr etc | 15:09 |
| freemangordon | it is empty | 15:10 |
| freemangordon | and I would expect errors in the log | 15:11 |
| Wizzup | maybe strace? | 15:12 |
| freemangordon | of Xorg?!? | 15:12 |
| Wizzup | sure | 15:13 |
| Wizzup | why not? | 15:13 |
| freemangordon | who will read that? | 15:13 |
| freemangordon | not me | 15:13 |
| * freemangordon hides :) | 15:13 | |
| Wizzup | I don't think it does a lot when screen is off | 15:13 |
| Wizzup | but maybe I am wrong | 15:13 |
| freemangordon | hmm | 15:13 |
| freemangordon | I'd rather attach gdb | 15:13 |
| Wizzup | for me, on my d4, currently, only upower takes about 8% cpu | 15:14 |
| Wizzup | and udev 5% | 15:14 |
| Wizzup | but that's probably just the usual full battery charging noise | 15:14 |
| freemangordon | is it on charger? | 15:14 |
| Wizzup | it was, yes | 15:14 |
| Wizzup | so I checked, Xorg does nothing with screen off | 15:15 |
| freemangordon | well, with Xorg running as root, avg current should be about 50mA | 15:15 |
| Wizzup | it's just in epoll_wait(3, ...) | 15:15 |
| Wizzup | but mine runs as root still | 15:15 |
| freemangordon | you attach strace? | 15:15 |
| Wizzup | sure | 15:15 |
| freemangordon | ok | 15:15 |
| Wizzup | weird, I am fully upgraded, but my xorg does not run as user | 15:16 |
| * Wizzup double checks repos | 15:16 | |
| freemangordon | how's that? | 15:16 |
| Wizzup | well, I am on chimaera-devel | 15:16 |
| Wizzup | and X runs as root | 15:16 |
| Wizzup | well I have one day uptime | 15:16 |
| Wizzup | let me reboot | 15:16 |
| Wizzup | (logging a bit of strace first) | 15:17 |
| Wizzup | does it also use more cpu when screen is off? | 15:17 |
| Wizzup | or, more power, at least | 15:17 |
| freemangordon | cpu is idle | 15:17 |
| Wizzup | hmm | 15:17 |
| freemangordon | maybe elogind behaves and opens some button | 15:18 |
| freemangordon | wait | 15:18 |
| freemangordon | Xorg runs as root here too | 15:18 |
| Wizzup | oh | 15:19 |
| Wizzup | was it about xinit running as user then? | 15:19 |
| freemangordon | wait | 15:19 |
| freemangordon | I edited xorg script | 15:19 |
| freemangordon | lemme check what is in it | 15:19 |
| freemangordon | ok, I don;t get that: | 15:22 |
| freemangordon | user 2534 2522 0 16:17 tty7 00:00:00 /bin/sh /usr/bin/startx -- -keeptty -logverbose 1 -noreset -s 0 -core | 15:22 |
| freemangordon | user 2564 2534 0 16:17 tty7 00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :0 -keeptty -logverbose 1 -noreset -s 0 -core vt7 -keeptty -auth /tmp/serverauth.r2yeDGTndy | 15:22 |
| freemangordon | root 2565 2564 1 16:17 tty7 00:00:05 /usr/lib/xorg/Xorg :0 -keeptty -logverbose 1 -noreset -s 0 -core vt7 -keeptty -auth /tmp/serverauth.r2yeDGTndy | 15:22 |
| freemangordon | why Xorg runs as root? | 15:23 |
| freemangordon | maybe it is normal, dunno | 15:24 |
| Wizzup | I don't think it is normal | 15:24 |
| Wizzup | when I type 'startx' as user on my laptop it runs as my user | 15:25 |
| freemangordon | on my ubuntu 18 it runs as root too | 15:25 |
| Wizzup | well, X, not Xorg | 15:25 |
| Wizzup | ubuntu 18 is old, that's normal there | 15:25 |
| Wizzup | merlijn 3424 0.0 0.0 4220 1672 tty1 S+ 12:42 0:00 xinit /home/merlijn/.xinitrc -- /etc/ | 15:25 |
| Wizzup | 11/xinit/xserverrc :0 -auth /tmp/serverauth.9uXoWqfL33 | 15:25 |
| Wizzup | merlijn 3425 2.0 0.3 1048196 58628 tty1 Sl 12:42 3:25 /usr/bin/X -nolisten tcp -keeptty :0 -auth /tmp/serverauth.9uXoWqfL33 vt1 | 15:25 |
| freemangordon | lemme check xserverrc | 15:26 |
| freemangordon | but those are whatever comes from the repo | 15:26 |
| * freemangordon is confused | 15:27 | |
| freemangordon | user 2505 2504 0 14:26 tty7 00:00:00 /usr/lib/xorg/Xorg :0 -keeptty -logverbose 1 -noreset -s 0 -core vt7 -keeptty -auth /tmp/serverauth.SGsW4YyKuo | 15:27 |
| freemangordon | this is VM | 15:27 |
| freemangordon | Wizzup: what the? | 15:28 |
| freemangordon | Wizzup: seems it has suid bit set: | 15:29 |
| freemangordon | -rwsr-sr-x 1 root root 9796 Mar 12 20:01 Xorg.wrap | 15:29 |
| freemangordon | but, it is the same on the VM, why it is different? | 15:30 |
| Wizzup | what is Xorg.wrap ? | 15:32 |
| freemangordon | a binary | 15:33 |
| Wizzup | dpkg -S ? | 15:33 |
| freemangordon | oh, wait | 15:34 |
| freemangordon | I think I found it | 15:34 |
| freemangordon | cat /etc/X11/Xwrapper.config | 15:34 |
| freemangordon | gives root on d4 and user in the VM | 15:34 |
| freemangordon | what the? | 15:34 |
| freemangordon | -rw-r--r-- 1 root root 630 May 16 2021 /etc/X11/Xwrapper.config | 15:35 |
| freemangordon | oh, scratch that | 15:36 |
| freemangordon | my fault | 15:36 |
| freemangordon | both have allowed_users=console | 15:36 |
| Wizzup | did you find it, or not? | 15:39 |
| freemangordon | no | 15:39 |
| freemangordon | lemme check Xorg.wrap code | 15:39 |
| Wizzup | fwiw I don't have Xorg.wrap on my laptop | 15:41 |
| freemangordon | bt in VM there is | 15:41 |
| freemangordon | *but | 15:41 |
| freemangordon | and it still runs as user | 15:41 |
| Wizzup | ok | 15:41 |
| Wizzup | |-dsme---dsme-server-+-alarmd | 15:42 |
| Wizzup | | |-autologin---startx---xinit-+-Xorg---{Xorg} | 15:42 |
| Wizzup | | | `-Xsession-post-+-maemo-xinput-so---2*[{maemo-xinput-so}] | 15:42 |
| Wizzup | freemangordon: doesn't dsmetool start autologin as root, or am I confused | 15:43 |
| Wizzup | (I don't know much about autologin) | 15:44 |
| Wizzup | yeah, autologin runs as root, is that intended? (could be) | 15:44 |
| uvos__ | ofc | 15:44 |
| uvos__ | autologin starts the session | 15:44 |
| uvos__ | it must be root | 15:44 |
| Wizzup | ok | 15:44 |
| Wizzup | startx seems to run at user as least | 15:44 |
| Wizzup | freemangordon: what even runs this wrap stuff? | 15:45 |
| uvos__ | xinit | 15:45 |
| uvos__ | this dose some magic to make xorg able to run as user | 15:45 |
| uvos__ | its setuid and gives it some resources like keyboard and mouse devies or some sutch | 15:46 |
| uvos__ | iirc | 15:46 |
| freemangordon | wait, I think I have an idea | 15:47 |
| Wizzup | xinit is not setuit | 15:47 |
| Wizzup | setuid* | 15:47 |
| freemangordon | this https://github.com/maemo-leste-upstream-forks/xorg-server/blob/maemo/beowulf/hw/xfree86/xorg-wrapper.c#L234 | 15:47 |
| Wizzup | at least on my d4 it is not | 15:47 |
| uvos__ | warp | 15:47 |
| uvos__ | not xinit itself | 15:47 |
| freemangordon | maybe DRM_IOCTL_MODE_GETRESOURCES fails on omap | 15:47 |
| Wizzup | where do these wrap come from? | 15:48 |
| Wizzup | I don't see them anywhere | 15:48 |
| freemangordon | from xorg package | 15:48 |
| freemangordon | see ^^^ | 15:48 |
| Wizzup | I see Xorg.wrap, but not xinit | 15:48 |
| Wizzup | oh, I see | 15:48 |
| freemangordon | will set needs_root_rights=no and will see | 15:49 |
| Wizzup | ok | 15:49 |
| freemangordon | user 2604 2603 5 16:53 tty7 00:00:04 /usr/lib/xorg/Xorg :0 -keeptty -logverbose 1 -noreset -s 0 -core vt7 -keeptty -auth /tmp/serverauth.7fOHNZMCmv | 15:55 |
| freemangordon | but idle consumption is still very high | 15:56 |
| freemangordon | maybe elogind opens some device and never closes it | 16:00 |
| freemangordon | yep, it has several /dev/input/eventN fds | 16:02 |
| Wizzup | ok, that's probably it then | 16:04 |
| Wizzup | but elogind runs no matter if we have root X or not, no? | 16:04 |
| Wizzup | why does elogind even have to open this? to read the power button? | 16:05 |
| Wizzup | man :( | 16:05 |
| Wizzup | it opens several more than once, too | 16:05 |
| freemangordon | I guess it does its stuff when we have a session | 16:05 |
| Wizzup | I don't think we want it to do -anything- with /dev/input | 16:06 |
| freemangordon | mhm | 16:06 |
| Wizzup | I need to go | 16:06 |
| Wizzup | back later | 16:06 |
| * freemangordon checks in the code how to do that | 16:06 | |
| freemangordon | ok | 16:06 |
| bencoh | sounds terrible tbh yeah | 16:08 |
| freemangordon | ok, but how does mce uses power button with no issue? | 16:12 |
| bencoh | doesn't mce close it when we disable display from hildon's UI? | 16:13 |
| bencoh | (be it double-press on power button or lock screen) | 16:13 |
| freemangordon | power button remains active when device is locked | 16:14 |
| freemangordon | no, this is something else | 16:14 |
| Wizzup | freemangordon: yes, that is kept open but kernelhas suspend iirc | 16:16 |
| freemangordon | killing elognd does not help | 16:16 |
| Wizzup | wrt power? | 16:17 |
| freemangordon | mhm | 16:17 |
| Wizzup | I think it confuses mce too | 16:17 |
| Wizzup | I was unable to use ts on my d4 | 16:17 |
| uvos__ | powerbutton (and cpcap keys in general) require no power to keep open | 16:17 |
| freemangordon | right | 16:17 |
| freemangordon | anyway, it is not elogind | 16:17 |
| Wizzup | so just killing elogind is not enough, it confuses mce | 16:17 |
| Wizzup | I am not sure if your test is valid | 16:18 |
| freemangordon | ah | 16:18 |
| freemangordon | lemme restart mce | 16:18 |
| freemangordon | yeah | 16:18 |
| freemangordon | cannot restart mce | 16:18 |
| uvos__ | so is it keeping the touchscreen event devices open (elogind)? | 16:18 |
| uvos__ | at any point | 16:19 |
| freemangordon | will check | 16:19 |
| uvos__ | killing elogind might also not remove the problem | 16:19 |
| uvos__ | because it might have change the autosuspend tuneables | 16:19 |
| uvos__ | or it could be something else entirely | 16:20 |
| Wizzup | uvos__: it has almost all open | 16:20 |
| freemangordon | if elogind opens TS that might explain it, no? | 16:20 |
| Wizzup | at all time | 16:20 |
| uvos__ | freemangordon: yes | 16:20 |
| uvos__ | that blocks ret | 16:20 |
| Wizzup | feature creep at its best | 16:23 |
| uvos__ | i mean logind handling power isent feature creep | 16:23 |
| uvos__ | what this is is bad implementation | 16:23 |
| uvos__ | (it should release when configured to not handle it) | 16:24 |
| freemangordon | https://pastebin.com/23Q4TzV4 | 16:24 |
| freemangordon | you can't configure it | 16:24 |
| Wizzup | uvos__: they go hand in hand | 16:25 |
| Wizzup | :P | 16:25 |
| uvos__ | freemangordon: whitch one of these is ts? | 16:25 |
| freemangordon | lemme check | 16:25 |
| uvos__ | the keyboard ones are not relevant | 16:25 |
| freemangordon | but, lemme check something first | 16:25 |
| uvos__ | the kernel itself never closes those | 16:25 |
| uvos__ | (it keeps those open for the vts) | 16:26 |
| Wizzup | I don' think we have 5 devices with power button | 16:26 |
| uvos__ | not but any device with EV_KEY | 16:26 |
| uvos__ | is open at all times by the kernel itself | 16:26 |
| uvos__ | so they dont matter | 16:26 |
| uvos__ | thats the keyboard and other stuff too | 16:26 |
| freemangordon | still, elogind should not keep devices it is not interested in open | 16:26 |
| Wizzup | unrelated but how does this work with ts keys | 16:26 |
| uvos__ | ts-buttons is "opertuneisitc" | 16:27 |
| uvos__ | ie it only reports keys when the touchscreen is open by some other source | 16:27 |
| uvos__ | yes this is a hack to work around this very problem | 16:28 |
| Wizzup | heh | 16:28 |
| freemangordon | what is the easiest way to check what is eventN? | 16:28 |
| uvos__ | freemangordon: right | 16:28 |
| uvos__ | ls -l /dev/input/by-path/ | 16:29 |
| freemangordon | ok, "Filtered touchscreen" is event2 | 16:29 |
| uvos__ | or udevadm | 16:29 |
| freemangordon | platform-mapphone_touchscreen-event -> ../event2 | 16:29 |
| uvos__ | yeah that costs a tone of power | 16:29 |
| freemangordon | lrwx------ 1 root root 64 Mar 14 17:23 20 -> /dev/input/event2 | 16:29 |
| freemangordon | right | 16:30 |
| freemangordon | that seems like a bug to me | 16:31 |
| freemangordon | not something intended | 16:31 |
| freemangordon | I see in elogind code that it is supposed to close devices that has no buttons elogind is interested in | 16:32 |
| uvos__ | systemd-logind | 16:33 |
| uvos__ | dosent appear to have all events open | 16:33 |
| uvos__ | just a couple | 16:33 |
| uvos__ | out of 20 on my PC | 16:33 |
| freemangordon | what is the version? | 16:33 |
| uvos__ | 253.1 | 16:34 |
| freemangordon | ummm.... | 16:34 |
| freemangordon | manager_all_buttons_ignored() :) | 16:34 |
| freemangordon | lemme try that | 16:34 |
| bencoh | < Wizzup> feature creep at its best / and that's with a supposedly light/standalone version of elogind ... :/ | 16:40 |
| uvos__ | im not sure how you expect logind to manage the session without knowing power key state and laptop lid state etc | 16:40 |
| uvos__ | its not feature creep at all | 16:40 |
| freemangordon | didn't help :( | 16:41 |
| uvos__ | report a bug, its seams a bug | 16:41 |
| uvos__ | systemd must have fixed it after the fork | 16:41 |
| freemangordon | well, I'll rather fix it and send a patch | 16:42 |
| uvos__ | sure | 16:42 |
| Wizzup | uvos__: is your systemd-logind the same version | 16:59 |
| freemangordon | no | 16:59 |
| freemangordon | 253.1 | 16:59 |
| Wizzup | maybe it is solved in new elogind too | 16:59 |
| arno11 | guys do you trust me if i say i'm chating with my wife on fb messenger using your conversations app ? | 18:13 |
| Wizzup | haze and libpurple for facebook? :) | 18:14 |
| Wizzup | I assume | 18:14 |
| Wizzup | cool in any case :D | 18:14 |
| arno11 | no lol localhost gateway with bitlbee | 18:14 |
| arno11 | and through irssi in conversations | 18:15 |
| arno11 | yes really cool | 18:15 |
| arno11 | and almost no power ressources | 18:15 |
| Wizzup | ah, check, that also works :D | 18:16 |
| arno11 | because bitlbee works with conversation it means | 18:16 |
| Wizzup | yeah, we do need to support groups in conversations | 18:16 |
| Wizzup | the code is there for it, kinda, but not in a release and UI for it is missing | 18:16 |
| Wizzup | I have slack working telepathy-haze and purple-slack | 18:17 |
| arno11 | cool | 18:17 |
| arno11 | twitter signal and telegram should work as well | 18:17 |
| arno11 | using bitlbee | 18:17 |
| Wizzup | I think this is libpurple, no? | 18:18 |
| Wizzup | so this can also work with telepathy-haze | 18:18 |
| bencoh | s/can/could/ I remember having issues with telepathy-haze and newer protocols (ie telegram) on fremantle | 18:19 |
| arno11 | it is another specific lib | 18:19 |
| Wizzup | arno11: https://wiki.bitlbee.org/ says through libpurple | 18:19 |
| Wizzup | (and extra lib ofc) | 18:19 |
| bencoh | iirc the issue was with auth | 18:19 |
| Wizzup | bencoh: all ssl on fremantle is no-go nowadays anyway | 18:20 |
| bencoh | yeah I mean, before that | 18:20 |
| arno11 | yeah but it needs bitlbee plugin facebook | 18:20 |
| arno11 | and needs a hack | 18:20 |
| arno11 | with a .so file | 18:20 |
| Wizzup | arno11: signal, or something else? | 18:20 |
| arno11 | bencoh: yeah but it works with a hack | 18:21 |
| arno11 | Wizzup: signal should work too | 18:22 |
| Wizzup | arno11: in any case, if it wasn't clear (maybe it was): bitlbee and telepathy-haze can both use libpurple and thus theoretically work with most pidgin plugins | 18:23 |
| Wizzup | so you can also definitely so slack on bitlbee, like I did for tp-haze | 18:23 |
| Wizzup | not pushing for any direction, just FYI | 18:23 |
| Wizzup | let me see if I can get my n900 attached to this serial | 18:24 |
| Wizzup | freemangordon: re: elogind, what do we plan to do, fix it and build ourselves until next release? | 18:24 |
| Wizzup | bookworm also has 246 | 18:25 |
| arno11 | Wizzup:ok everything is clear | 18:25 |
| Wizzup | :) | 18:25 |
| freemangordon | Wizzup: yeah, sounds like a plan | 18:28 |
| freemangordon | but it is extremely hard to find where are those opened | 18:28 |
| Wizzup | no surprise there :D | 18:40 |
| Wizzup | does it use libinput? | 18:40 |
| freemangordon | what I think happens here is that is kinda "shadows" the real devices for user session | 18:41 |
| Wizzup | freemangordon: and if we set HandleLidSwitch=ignore, and same for all the others, does it still open event files? | 18:42 |
| freemangordon | yes | 18:42 |
| freemangordon | because those get opened by session_device_open() | 18:42 |
| freemangordon | this is a result of a dbus call | 18:42 |
| Wizzup | ok | 18:42 |
| Wizzup | hmm.. | 18:43 |
| Wizzup | >Only input devices with the "power-switch" udev tag will be watched for key/lid switch events. | 18:43 |
| Wizzup | from https://www.freedesktop.org/software/systemd/man/logind.conf.html | 18:43 |
| freemangordon | yes, but we hit something differenet | 18:44 |
| freemangordon | maybe when session process opens a device, this gets opened by elogind too | 18:44 |
| Wizzup | ok | 18:45 |
| Wizzup | that would be absolutely insane @ mirroring | 18:45 |
| Wizzup | or shadowing | 18:45 |
| Wizzup | that can't be it | 18:45 |
| freemangordon | see https://pastebin.com/w9zmNPGm | 18:46 |
| freemangordon | this is for "/dev/input/event5" | 18:47 |
| freemangordon | in VM | 18:47 |
| freemangordon | ok, leme retry with dbus-monitor | 18:48 |
| Wizzup | maybe this is the 'tracking' that it does or something | 18:51 |
| freemangordon | could be | 18:51 |
| Wizzup | I just confirmed that setting *all* of the HandleBlaBla=ignore doesn't help | 18:53 |
| freemangordon | already tried, but ok | 18:54 |
| Wizzup | didn't know that | 18:54 |
| freemangordon | se, this is TakeDevice method | 18:54 |
| freemangordon | *so | 18:54 |
| Wizzup | https://blog.martin-graesslin.com/blog/2016/12/how-input-works-creating-a-device/ | 18:54 |
| freemangordon | "TakeDevice() allows a session controller to get a file descriptor for a specific device." | 18:55 |
| Wizzup | it seems to be somehow facilitating libinput | 18:55 |
| freemangordon | oh, ok | 18:57 |
| freemangordon | sec | 18:57 |
| freemangordon | https://github.com/maemo-leste-upstream-forks/xorg-server/blob/maemo/beowulf/hw/xfree86/os-support/linux/systemd-logind.c#L86 | 18:58 |
| freemangordon | see this | 18:58 |
| Wizzup | sigh | 18:59 |
| Wizzup | I guess we will probably have to add logind specific code to tell it to drop the devices, just disabling it in xorg isn't enough | 18:59 |
| freemangordon | it should be | 19:00 |
| freemangordon | or rather | 19:00 |
| freemangordon | xf86DeleteInput() calls systemd_logind_release_fd | 19:01 |
| freemangordon | Wizzup: we have to add code where? | 19:01 |
| freemangordon | Wizzup: uvos__: what do we use now to disable input devices? | 19:03 |
| freemangordon | XInputDisable? | 19:03 |
| * freemangordon checks mce code | 19:04 | |
| freemangordon | x11_set_input_device_enabled | 19:05 |
| * freemangordon wonders where this end up in server code | 19:05 | |
| Wizzup | x11_set_input_device_enabled that sounds like a helper function in mce | 19:06 |
| Wizzup | or is this libinput? | 19:06 |
| freemangordon | sorry, helper | 19:06 |
| freemangordon | XIChangeProperty | 19:06 |
| freemangordon | "Device Enabled" atom it seems | 19:07 |
| freemangordon | p, li { white-space: pre-wrap; } XI_PROP_ENABLED | 19:07 |
| Wizzup | yeah, that sounds like normal X way | 19:08 |
| freemangordon | ok, but where this ends up? | 19:09 |
| Wizzup | don't know | 19:17 |
| freemangordon | Wizzup: ok, seems we will have to cheat | 19:34 |
| Wizzup | sounds fun :D | 19:34 |
| freemangordon | xorg does not support releasing input devices, but elogind can 'pause' them | 19:34 |
| freemangordon | in order to do that we should activate another session | 19:35 |
| freemangordon | not sure how to do that though | 19:35 |
| Wizzup | oh god | 19:35 |
| Wizzup | can we just not have xorg tell elogind about input devices? | 19:35 |
| freemangordon | no | 19:36 |
| freemangordon | multi-session will not work then | 19:36 |
| freemangordon | as xork will keep devices open | 19:36 |
| freemangordon | *xorg | 19:37 |
| Wizzup | does this bother us? | 19:37 |
| freemangordon | well | 19:38 |
| freemangordon | lemme check something | 19:38 |
| Wizzup | btw, what do you mean, xorg does not support releasing input devices | 19:38 |
| Wizzup | you can definitely get xorg to close the fds | 19:38 |
| freemangordon | do you know where that happens? | 19:39 |
| * freemangordon checks if this is fixed in upstream xorg | 19:39 | |
| Wizzup | no, I will have to look, but I can try to see | 19:39 |
| Wizzup | I mean we know xorg closes them for a fact, that's why without elogind, things work fine | 19:39 |
| Wizzup | pm wise | 19:39 |
| freemangordon | yes | 19:40 |
| Wizzup | freemangordon: dix/devices.c DisableDevice ? | 19:42 |
| freemangordon | (void) (*dev->deviceProc) (dev, DEVICE_OFF); | 19:42 |
| Wizzup | you can break on that in gdb for sure | 19:42 |
| freemangordon | yeah | 19:44 |
| Wizzup | seems to call Disable() on whatever the abstract driver is, if hw/kdrive/src/kinput.c is the right place to look | 19:45 |
| freemangordon | what is kdrive in that contaxt? | 19:45 |
| Wizzup | not sure | 19:45 |
| freemangordon | *context | 19:45 |
| Wizzup | I can't find another more reasonable place/file where DEVICE_OFF is used | 19:45 |
| freemangordon | hmmm | 19:47 |
| freemangordon | DisableDevice is not called in the VM | 19:48 |
| freemangordon | when I lock the screen that is | 19:48 |
| freemangordon | neither is DeviceSetProperty | 19:49 |
| freemangordon | what the? | 19:49 |
| Wizzup | maybe this is libinput magic | 19:51 |
| freemangordon | xinput --set-prop 12 "Device Enabled" 0 makes it hit the breakpoint | 19:52 |
| Wizzup | what does mce do then? | 19:52 |
| freemangordon | maybe mce does not work properly in VM | 19:52 |
| Wizzup | (if not that) | 19:52 |
| freemangordon | no idea | 19:52 |
| freemangordon | uvos__: ^^^? | 19:53 |
| Wizzup | lol this is really quite hilarious, it doesn't seem to ever release fds unless it fails to grab them or something | 19:55 |
| freemangordon | Wizzup: yes, because xorg does not control those fds anyways | 19:55 |
| freemangordon | it is elogind that does it | 19:56 |
| Wizzup | none of this makes any sense to me, but I am probably just grumpy | 19:56 |
| freemangordon | and it just send PauseDevice signal | 19:56 |
| freemangordon | imagine, if you switch the session | 19:56 |
| freemangordon | your active session should receive kbd input, no? | 19:56 |
| Wizzup | I don't see why X cannot close input devices if it is not active, but I guess there is no point in discussing why elogind works the way it does | 19:57 |
| Wizzup | we can't change that anyhow | 19:57 |
| freemangordon | because it didn;t opent them in first place :) | 19:57 |
| Wizzup | freemangordon: if it does open them in the first place, it's fine | 19:58 |
| Wizzup | also keep in mind that most input devices can be opened many times | 19:58 |
| freemangordon | well, we'd better fix that properly | 19:58 |
| Wizzup | why can't elogind let go of the fd? | 19:58 |
| Wizzup | I don't see how that factors in to the switching | 19:58 |
| freemangordon | elogind will close fds, if we somehow tell it to do so | 19:59 |
| Wizzup | so why doesn't X? | 19:59 |
| freemangordon | like, switch the session | 19:59 |
| freemangordon | because X just asked elogind to open fds for it | 19:59 |
| freemangordon | anyway | 19:59 |
| Wizzup | so: | 19:59 |
| freemangordon | this makes sense to me | 19:59 |
| Wizzup | xorg without elogind: | 19:59 |
| Wizzup | 1. opens input devices by default | 19:59 |
| Wizzup | 2. when input disabled, closes fd | 19:59 |
| Wizzup | why can't it do the same with elogind? | 20:00 |
| freemangordon | I think this is more complicated | 20:00 |
| freemangordon | it seems this is libinput that does the magic | 20:00 |
| freemangordon | ummm | 20:00 |
| freemangordon | sorry | 20:00 |
| freemangordon | Thread 1 "Xorg" hit Breakpoint 4, 0x00007f459b5c18a0 in ?? () from /usr/lib/xorg/modules/input/libinput_drv.so | 20:00 |
| freemangordon | libinput_drv.so | 20:00 |
| freemangordon | Wizzup: this ends up in xf86libinput_off() which in turn calls xf86SetIntOption(pInfo->options, "fd", -1); | 20:04 |
| freemangordon | see https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/blob/master/src/xf86libinput.c#L944 | 20:06 |
| Wizzup | ok | 20:06 |
| freemangordon | and where this ends is the million dollars question :) | 20:07 |
| freemangordon | see the note there https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/blob/master/src/xf86libinput.c#L914 | 20:09 |
| freemangordon | Wizzup: I don't get that note | 20:13 |
| Wizzup | (sry, work mtg) | 20:13 |
| freemangordon | ok | 20:13 |
| Wizzup | back | 21:27 |
| freemangordon | Wizzup: maybe I can patch xorg to ReleaseDevice() on disable | 21:44 |
| freemangordon | but, maybe we shall drop logind session (and run Xorg as root) until done | 21:44 |
| freemangordon | it will take me some time to patch it | 21:45 |
| arno11 | Sorry guys but is there a magic command to get pin entry code working or is it broken on n900 ? | 21:45 |
| freemangordon | BTW, didn;t mce use dpms to disable devices? | 21:45 |
| freemangordon | pin entry? SIM pin? | 21:46 |
| arno11 | sim pin | 21:46 |
| freemangordon | it should work | 21:47 |
| freemangordon | Wizzup: https://github.com/maemo-leste/mce/blob/master/src/modules/x11-ctrl.c#L257 | 21:48 |
| freemangordon | arno11: sorry, my comment was not very helpful :) | 21:48 |
| arno11 | ok lol no probs | 21:48 |
| arno11 | you're working hard i know | 21:48 |
| freemangordon | does ofono report that SIM requires PIN? | 21:48 |
| arno11 | nope nothing happened in fact | 21:49 |
| arno11 | ofono is not ready | 21:49 |
| Wizzup | freemangordon: well for non-devel chimaera we have this, right? | 21:50 |
| freemangordon | yes | 21:50 |
| freemangordon | arno11: well, of ofono is not ready... | 21:50 |
| freemangordon | *if | 21:50 |
| arno11 | always this message | 21:50 |
| Wizzup | arno11: does ofono see the modem? | 21:50 |
| arno11 | no | 21:50 |
| freemangordon | Wizzup: ok, will see what I can do during the weekend | 21:51 |
| arno11 | freemangordon:i mean sms app says: ofono is not ready | 21:53 |
| Wizzup | I am fine with running X as root fwiw | 21:53 |
| Wizzup | arno11: mdbus2 is probably a good way to debug ofono's state | 21:53 |
| Wizzup | and fwiw startup-pin-query is the program to run for getting the pin gtk dialog | 21:53 |
| arno11 | ok i'll try | 21:53 |
| Wizzup | (normally it runs on boot) | 21:53 |
| arno11 | ok thx guys | 21:53 |
| Wizzup | arno11: https://packages.debian.org/stretch/armhf/mdbus2/download | 21:53 |
| Wizzup | you can dpkg -i it I think | 21:54 |
| arno11 | cool | 21:54 |
| sicelo | or ofono-scripts | 21:55 |
| sicelo | output of ` sudo dmesg | grep 'modem\|ssi' ` might also be interesting to see | 21:56 |
| arno11 | ah ok | 21:56 |
| Wizzup | I find ofono-scripts less useful, but yes, that can work too | 21:56 |
| arno11 | interesting | 21:58 |
| arno11 | i'll try all of that and let you know guys | 21:58 |
| arno11 | thx | 21:58 |
| freemangordon | Wizzup: startup-pin-query is *not* run on boot :) | 21:59 |
| freemangordon | it is run by status menu plugin once SIM/modem is ready | 21:59 |
| freemangordon | ugh | 22:00 |
| freemangordon | Wizzup: see https://github.com/maemo-leste/connui-cellular/commit/e1122bf8a723eb80ee7c1f53c191f44a3f72a6ab | 22:00 |
| Wizzup | freemangordon: so effectively on boot :P | 22:00 |
| freemangordon | I hope this is in chimaera | 22:00 |
| Wizzup | should be, I use it daily | 22:00 |
| freemangordon | no, if you boot d4 with no SIM and then hot-plug, it will *then* ask you | 22:01 |
| freemangordon | ok, it is in chimaera, but not in master | 22:01 |
| freemangordon | lemme fix that | 22:01 |
| Wizzup | uvos__: on my laptop: | 22:32 |
| Wizzup | # ls -lsh /proc/2408/fd | grep event | grep input | wc -l | 22:32 |
| Wizzup | 17 | 22:32 |
| Wizzup | elogind opened just about every eventX that existed | 22:32 |
| uvos | what version is that | 22:42 |
| uvos | are any of the previous questions to me still relevant wrt mce etc? | 22:43 |
| uvos | dpms is not relevant to input devices | 22:45 |
| uvos | this is for crts | 22:45 |
| uvos | *crtcs | 22:46 |
| buZz | dpms likely gets stopped by input devices? | 22:46 |
| uvos | xorgs dpms extension manages crtc state based on input devices yes, avoid that is why we disable all input devices on blank, instead of just the ts | 22:47 |
| uvos | but this is not relevant to this discussion | 22:47 |
| Wizzup | uvos__: 246.10-r2 | 22:51 |
| uvos | one annyoing thing with startup-pin-query is that if you accidentaly click above it (ie dissmissing it) there is no way to get it back | 22:57 |
| uvos | but that would be a easy fix with a .desktop file to runn it again | 22:57 |
| Wizzup | you can go to settings and get it back | 22:58 |
| Wizzup | settings->phone | 22:58 |
| Wizzup | but yes | 22:58 |
| Wizzup | this is something we'll have to fix later/eventually | 22:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!