| Wizzup | still weird to see status applet say battery is fully charged, but have mce not show the green led | 03:09 |
|---|---|---|
| Wizzup | sicelo: btw, confirmed that up to date n900 on leste also suffers from ts being open in elogind/xorg bug | 03:27 |
| * Wizzup zz | 03:27 | |
| sicelo | does the mce battery full thing work on droid 4 or something else? | 07:16 |
| sicelo | oh btw droid 4 always shows green ... | 07:18 |
| sicelo | i guess mce already does something like turn led green if charger online && capacity > 96% ? | 08:03 |
| sicelo | Wizzup: 9a36f9f25c9440e412b672c mce - i would say those need to be blacklisted at kernel level. i was going to say remove from config but i guess kernel blacklist will be easier | 08:05 |
| Wizzup | 07:16 < sicelo> does the mce battery full thing work on droid 4 or something else? | 13:00 |
| Wizzup | no, but it used to work on the n900 when spinal was working on it | 13:00 |
| Wizzup | maybe it's a kernel thing, or upower thing | 13:00 |
| Wizzup | sicelo: I disagree, we already had a blacklist in place, so having it in mce for now makes sense to me, but yeah, fine to do in the kernel too, but I don't have the time and skill to do it | 13:01 |
| sicelo | ok | 13:01 |
| sicelo | i meant blacklist the module from loading, but yeah, anything that works is fine | 13:02 |
| Wizzup | hmmm | 13:03 |
| Wizzup | well, we can do in parallel | 13:03 |
| Wizzup | do you think this will not interfere with the functioning of the rest? | 13:03 |
| Wizzup | because I think some of these we need, but we just don't want upower to use them | 13:04 |
| Wizzup | I mean sure there's this one useless rx51 battery, but the rest, I think we need | 13:04 |
| sicelo | we don't need these drivers on n900 | 13:06 |
| Wizzup | ok, then let's work on a blacklist for these as well | 13:07 |
| Wizzup | so I checked and maemo-system-services is at the new/fixed version | 13:16 |
| Wizzup | and the input dev getting disabled seems to suggest mce does its thing | 13:16 |
| Wizzup | but why does X keep it open now | 13:16 |
| Wizzup | freemangordon: so I see DisableDevice get called in X | 13:29 |
| Wizzup | but elogind and X do not free it | 13:29 |
| arno11 | Wizzup:i can confirm as well elogin/xorg ts issue on n900 but by chance I have still an old img | 13:29 |
| arno11 | from march 13 | 13:30 |
| arno11 | last dist-upgrade march 15 | 13:30 |
| arno11 | and issue already there | 13:30 |
| arno11 | kernel 6.0 bla bla rc | 13:30 |
| arno11 | otherwise no inpact on power consumption | 13:32 |
| Wizzup | I'm pretty sure the problem is with elogind and X running in user mode | 13:32 |
| Wizzup | I'm retracing our steps | 13:32 |
| arno11 | on my old img x and elogin run as root | 13:33 |
| Wizzup | yes, I think this is it | 13:34 |
| arno11 | but the issue is already there | 13:34 |
| Wizzup | this is with old maemo system services | 13:34 |
| Wizzup | if you upgrade just that it should be fixed | 13:35 |
| Wizzup | I think what happened is that we figured out half of the problem: mce wasn't able to disable the devices when X ran as root | 13:35 |
| Wizzup | but the other half: X and elogind not actually releasing the fd when X runs as user, was not solved | 13:35 |
| arno11 | so 2 different issues ? | 13:36 |
| Wizzup | 21:45 < freemangordon> but, maybe we shall drop logind session (and run Xorg as root) until done | 13:36 |
| Wizzup | let me try something | 13:37 |
| Wizzup | lol, another loop-break apt upgrade | 13:50 |
| Wizzup | hm, even with the xorg legacy pkg installed this still happens | 13:51 |
| Wizzup | :( | 13:51 |
| Wizzup | I am out of options right now | 13:51 |
| arno11 | I've just upgraded maemo system services on old img to check difference | 13:56 |
| arno11 | no change | 13:56 |
| arno11 | still root and ts issue | 13:56 |
| Wizzup | phone call, brb | 13:57 |
| arno11 | Wizzup:ttyl have to go too | 13:57 |
| Wizzup | so I think the short term solution is to just not build X with logind support | 14:17 |
| Wizzup | we will still get the sessions any everything | 14:17 |
| Wizzup | it'll just run as root | 14:17 |
| Wizzup | yeah, with xorg-server built without logind everything is fine pm-wise | 14:39 |
| Wizzup | so there is really some unique breakage there in the logind code | 14:39 |
| Wizzup | I think this is probably what we want to do | 14:40 |
| Wizzup | brb\ | 14:41 |
| Wizzup | so I think what happened is that I promoted the -devel xorg-server a while back when talking with fmg even thoguh we should not have since it has this bug | 15:01 |
| Wizzup | wait.... `user` is not in the `input` group | 15:02 |
| Wizzup | I think that can be a problem too, but I am not sure if that's why we have this problem | 15:03 |
| Wizzup | freemangordon: ^^ | 15:03 |
| freemangordon | what is the isuue? | 15:46 |
| freemangordon | *issue | 15:46 |
| Wizzup | freemangordon: hi! | 15:47 |
| Wizzup | freemangordon: on chimaera now, ts is again now released by xorg and elogind | 15:47 |
| Wizzup | and it's unrelated to the problem we saw before with mce not disabling it | 15:47 |
| Wizzup | mce disables it, but X still does not release | 15:47 |
| Wizzup | I went down our previous steps trying to figure out what is up | 15:47 |
| freemangordon | on which device? | 15:47 |
| Wizzup | all | 15:47 |
| freemangordon | on d4? | 15:47 |
| Wizzup | d4, n900, etc | 15:48 |
| Wizzup | and I think the problem is that I moved xorg with elogind support to chimaera | 15:48 |
| freemangordon | not possible, I have more than 24 hours idle, but still lemme check the current | 15:48 |
| Wizzup | ok, well, lsof shows it | 15:48 |
| Wizzup | and power usage shows it | 15:48 |
| Wizzup | we all have the problem | 15:48 |
| Wizzup | I've fixed it in -devel for now by downgrading to xorg without elogind (everything else still works) | 15:48 |
| freemangordon | ok | 15:49 |
| freemangordon | sorry, just came home, will need some time to catch up | 15:49 |
| Wizzup | I think the above is the whole summary really | 15:50 |
| Wizzup | unless you're sure you had it working before with xorg with elogind support enabled | 15:50 |
| freemangordon | well, I was seeing the smae average current | 15:50 |
| freemangordon | *same | 15:50 |
| freemangordon | lets have my d4 battery charged, will check what's going on | 15:51 |
| freemangordon | ttyl | 15:51 |
| Wizzup | cheers | 15:52 |
| Wizzup | d=2023-04-02|t=16:15:39|i=OFF:0,RET:6319|p=96|c=NA|b=none | 16:16 |
| Wizzup | I get this reliably now | 16:16 |
| Wizzup | (with wifi off) | 16:17 |
| bencoh | 96mW? | 16:17 |
| Wizzup | looks like it | 16:17 |
| Wizzup | it jumps a bit to 105 some of the time | 16:18 |
| Wizzup | with modem on | 16:18 |
| Wizzup | arno11: if you dist-upgrade on -devel the pm issue should be gone | 16:40 |
| tmlind | Wizzup: yup that looks better for power consumption | 16:46 |
| Wizzup | tmlind: right, so with this I can look again at the neigh probe stuff | 16:47 |
| tmlind | Wizzup: ok, that's still about 20mW higher compared to what i'm seeing on alpine with wlan off 3g voice and data online | 16:47 |
| tmlind | and i think we still have some mystery 5 - 7mW of idle saving lurking around in some d4 device | 16:48 |
| tmlind | just a gut feeling though | 16:48 |
| arno11 | Wizzup: ok i'll try in a bit but i never had pm issue | 16:50 |
| Wizzup | tmlind: it could perhaps also be my device, I've had one or two droids that just used more power, even when turned off i saw them use power on lab psu | 16:51 |
| Wizzup | might not be this one | 16:51 |
| tmlind | ok | 16:52 |
| Wizzup | I might be worth at some point to upgrade to -devel on yours and check (the ts not being closed bug is worked around there) | 16:52 |
| arno11 | Wizzup:there is no inpact on n900 pm and it's logical | 16:54 |
| Wizzup | arno11: well it will be a pm issue I think, on n900 there used to be a kernel hack to force suspend the ts, but I think that is gone | 16:54 |
| Wizzup | arno11: how is that logical? | 16:54 |
| arno11 | because touch screen is never really off | 16:55 |
| Wizzup | arno11: what do you mean? | 16:55 |
| Wizzup | it should be | 16:55 |
| arno11 | remember pm stuff with n900, we can't hit ret or off mode because of screen | 16:56 |
| Wizzup | so what I know is that with ff62b5a2d7c4794659b626469b30d4fce43fdcbf and 34df5ff446f3b03f2dc4f1049fa57db544cd7b66 the screen idles ok with fd closed | 16:57 |
| arno11 | elogin and x issue or not, idle is still the same | 16:57 |
| Wizzup | that is | 16:57 |
| Wizzup | wip: Input: tsc200x-core: use runtime PM instead of custom functions | 16:57 |
| Wizzup | and | 16:57 |
| Wizzup | wip: Input: tsc2005: disable irqs on suspend | 16:57 |
| Wizzup | and we ship this | 16:57 |
| Wizzup | however, note that the ts is only released when the device is locked | 16:57 |
| Wizzup | that is not the same as 'screen off' | 16:57 |
| Wizzup | so you need to use double power button press or lock screen slider | 16:58 |
| Wizzup | let me check this on my n900 | 16:58 |
| arno11 | ok | 16:58 |
| arno11 | weird | 16:58 |
| Wizzup | btw latest kernel also has the pm debugging sysfs file | 16:58 |
| Wizzup | well I guess this depend on the setting that auto locks the screen or not | 17:01 |
| Wizzup | arno11: how many mW did you normally see? | 17:03 |
| arno11 | I've just triplecheck and everything is fine as always | 17:03 |
| Wizzup | do you mean that X does not hold the touchscreen open? | 17:03 |
| arno11 | 50mW /185mW as usual | 17:04 |
| Wizzup | arno11: sorry, this is screen off / on? | 17:04 |
| arno11 | i'm just saying that elogin issue or not, i have the same idle | 17:04 |
| arno11 | off | 17:04 |
| arno11 | sorry 50mA/185mW | 17:05 |
| Wizzup | I see two values | 17:05 |
| Wizzup | ok | 17:05 |
| arno11 | giving more than 24 hours | 17:05 |
| Wizzup | I am seeing p=230mW right now, with wifi off | 17:07 |
| Wizzup | d=2023-04-02|t=17:06:24|i=OFF:0,RET:0|p=230|c=91|b=ST_SDRC,ST_SDMA,ST_OMAPCTRL,ST_I2C1 | 17:07 |
| Wizzup | the b= are the blockers | 17:07 |
| arno11 | that's quite a lot | 17:07 |
| Wizzup | with modem on | 17:08 |
| Wizzup | in any case, if you want I can try to see what happens if I keep the ts actually enabled, but I'm sure it will use a lot more power | 17:08 |
| Wizzup | unless the kernel misbehaves, which is possible, since it's my patch | 17:08 |
| arno11 | yes could be interesting | 17:08 |
| Wizzup | like: userspace should never keep ts open, ever, if it doesn't need it | 17:09 |
| Wizzup | since that means the ts will be powered | 17:09 |
| Wizzup | btw it looks like the check bl-5j's I bought are really poor, like less than 400mAh :D | 17:09 |
| Wizzup | (they were not polarcell) | 17:09 |
| Wizzup | s/check/ceap/ | 17:09 |
| Wizzup | cheap* even | 17:09 |
| arno11 | ah could explain that | 17:09 |
| Wizzup | arno11: but, you see lsof keeping ts open now, or not? | 17:10 |
| Wizzup | just to see where you're at atm | 17:10 |
| arno11 | yes ts open in lsof | 17:10 |
| Wizzup | also, if you download the n900 pm script and don't start it, just run status, we can compare blockers and such (even with off/ret not enabled) | 17:10 |
| Wizzup | ok, well, I think if you upgrade to -devel and reboot, you will see it probably use less power | 17:10 |
| arno11 | ok but there is a bias i forgot | 17:11 |
| arno11 | i'm a bit undervolted | 17:11 |
| arno11 | with custom uImage | 17:11 |
| bencoh | undervolted? | 17:12 |
| arno11 | yes | 17:12 |
| arno11 | opp table modified | 17:12 |
| bencoh | oh | 17:12 |
| arno11 | and overclocked to 850 | 17:12 |
| bencoh | hmm, is it still stable? | 17:13 |
| arno11 | very stable | 17:13 |
| arno11 | and much more smooth | 17:13 |
| Wizzup | hard to compare then yeah :D | 17:14 |
| arno11 | yes indeed | 17:14 |
| Wizzup | in any case I will modify leste-config to add swap on emmc by default to fstab, but not only once and not if there is some other entry | 17:14 |
| arno11 | ok cool | 17:14 |
| Wizzup | then I guess we need.. phone audio, some ofono fixes eventually, and better pm | 17:15 |
| Wizzup | (for n900) | 17:15 |
| arno11 | yes we are not so far | 17:15 |
| Wizzup | 230mW seems like my regular idle mW btw | 17:15 |
| arno11 | ok so arround 60mA | 17:15 |
| bencoh | I think fmg has had his main n900 overclocked for years, but I don't think he undervolted it ... | 17:15 |
| Wizzup | bencoh: there's no need with ret/off working | 17:16 |
| bencoh | true | 17:16 |
| bencoh | idle power on fremantle is quite low as it is | 17:16 |
| arno11 | bencoh: every known overclocked profiles from fremantle are undervolted | 17:17 |
| Wizzup | very low :) | 17:17 |
| Wizzup | arno11: well if you can confirm that latest devel with the ts closed idles even better, I'd like to know | 17:17 |
| Wizzup | also, lmk what you did on phone audio so we can get back to pavel | 17:18 |
| arno11 | ok but i need time because to compare with my previous idle, i need to create a new uImage with same parameters | 17:19 |
| Wizzup | oh, right | 17:19 |
| Wizzup | well, conceptually it should really help :P | 17:19 |
| arno11 | so let's go | 17:19 |
| arno11 | back in 20-30min with results | 17:20 |
| Wizzup | but also conceptually you should have seen this before any of our elogind work | 17:20 |
| Wizzup | (this = the idle saving) | 17:20 |
| Wizzup | s/idle/power/ | 17:20 |
| arno11 | never seen any difference | 17:26 |
| arno11 | (dist-upgrading...) | 17:26 |
| arno11 | Wizzup:"lmk what you did on phone audio so we can get back to pavel" ok | 17:28 |
| arno11 | (arghhh force loopbreak option i don't like that lol) | 17:32 |
| arno11 | anyway seems to work | 17:32 |
| arno11 | rebooting and then creating new uImage | 17:36 |
| Wizzup | cool | 17:47 |
| buZz | hmmm weird, my d4 lost(?) its calibration while being on charge overnight | 17:48 |
| buZz | seemingly didnt reboot | 17:48 |
| buZz | guess i'll just discharge to 'omg charge now' and charge it all the way up | 17:49 |
| arno11 | ok uImage created...rebooting | 17:53 |
| arno11 | uImage seems fine. loading | 17:55 |
| arno11 | Wizzup: ok let's testing and compare | 17:58 |
| arno11 | no difference 46mA | 18:00 |
| arno11 | as usual | 18:00 |
| Wizzup | and if you run cat /dev/input/eventX >/dev/null where X is the ts? | 18:01 |
| Wizzup | (and then measure) | 18:01 |
| arno11 | ok let's go | 18:04 |
| arno11 | no difference same result | 18:05 |
| arno11 | let's try again to be sure | 18:05 |
| arno11 | still 47mA | 18:07 |
| Wizzup | ok | 18:09 |
| Wizzup | sounds like my kernel patches for pm are not enough then | 18:09 |
| Wizzup | thanks for verifying | 18:09 |
| Wizzup | seems like we can get lower pm then still even without ret | 18:10 |
| arno11 | yes totally agree! | 18:11 |
| buZz | 47mA is already amazing to me :D | 18:12 |
| arno11 | it's really great arround 27 hours idle ;) | 18:13 |
| arno11 | modem on 52mA | 18:13 |
| arno11 | btw user experience should be really different using custom overclock kernel. i didn't talk to much about that but the n900 is so much responsive...comparable to overclock fremantle | 18:26 |
| arno11 | even better playing videos | 18:26 |
| buZz | :) cool | 18:27 |
| buZz | even youtube? | 18:27 |
| arno11 | yes using yt-dlp | 18:27 |
| arno11 | and 360p | 18:27 |
| buZz | nice nice | 18:27 |
| arno11 | even kodi is working | 18:28 |
| arno11 | 17.6 | 18:28 |
| arno11 | and for me the most impressive stuff is retroarch | 18:29 |
| arno11 | impossible to run on fremantle afaik | 18:29 |
| buZz | why not the actual emulators? | 18:29 |
| arno11 | not really working on n900 | 18:30 |
| arno11 | i mean snes, nes, megadrive | 18:30 |
| arno11 | scummvm runs fine | 18:31 |
| buZz | arno11: gee, not even picodrive? | 18:34 |
| arno11 | picodrive doesn't work (even the retroarch module) | 18:34 |
| arno11 | but through retroarch, genesis gx works well | 18:35 |
| buZz | gee | 18:38 |
| Wizzup | documenting all of this would be real cool btw | 18:41 |
| Wizzup | we have people who do fun stuff with leste but then others have to jump through the same hoops | 18:41 |
| Wizzup | but I know, E_TIME :D | 18:41 |
| arno11 | :) | 18:42 |
| Wizzup | I have my macro lens set up now to make some photos of the batteries | 18:45 |
| arno11 | oops i've to go. i will try to find time to document fun stuff. | 18:47 |
| freemangordon | Wizzup: seems we are going in circles :) https://elixir.bootlin.com/linux/latest/source/include/linux/input.h#L132 | 19:14 |
| freemangordon | I remember dmitry refusing n900 patch to disable TS back then | 19:15 |
| Wizzup | lol | 19:16 |
| Wizzup | I think I just broke the eb41 pcb | 19:16 |
| Wizzup | so probably my attempt to document it with my macro lens stops here | 19:16 |
| freemangordon | baaad | 19:16 |
| Wizzup | yup | 19:17 |
| Wizzup | just confirmed :) | 19:17 |
| Wizzup | well, in another month or two I can try again | 19:17 |
| Wizzup | https://wizzup.org/IMG_8260.JPG | 19:20 |
| bencoh | is that the battery control board? | 19:23 |
| Wizzup | I guess so, yeah | 19:23 |
| Wizzup | I didn't think it'd be this big and also didn't think it'd be so hard to remove | 19:23 |
| buZz | its similar difficult to other batteries :) | 19:24 |
| Wizzup | what can I say, I'm a sw guy | 19:25 |
| bencoh | :) | 19:27 |
| Wizzup | I don't have any spare one here though, so it'll probably be sometime in June I will try again :D | 19:27 |
| buZz | i want to order another LG cell , and redo my attempt | 19:28 |
| buZz | but will have to be >1 month from now i guess | 19:28 |
| Wizzup | freemangordon: in case it wasn't clear, my lol was @ the inhibited property | 19:29 |
| Wizzup | I guess someone with more political capital asked him the same | 19:30 |
| freemangordon | Wizzup: yeah | 19:33 |
| freemangordon | so, we can fix both issues now - idle current usage and volume keys ;) | 19:34 |
| freemangordon | 3% remaining until my battery is full, then will see how inhibiting TS helps on idle consumption | 19:34 |
| freemangordon | hmm, we have to disable 2 devices | 19:38 |
| Wizzup | what do you mean with volume keys btw | 19:39 |
| freemangordon | using them when the device is locked | 19:39 |
| Wizzup | ah | 19:40 |
| freemangordon | now we can't do that | 19:41 |
| freemangordon | afaik | 19:41 |
| Wizzup | I don't think we disable all devices | 19:42 |
| Wizzup | so what kernel was this added | 19:42 |
| freemangordon | lemme check | 19:42 |
| Wizzup | it might not be exposed to userspace, too? | 19:43 |
| freemangordon | 5.11 | 19:44 |
| freemangordon | it is | 19:44 |
| freemangordon | check your sysfs eventX | 19:44 |
| freemangordon | Wizzup: btw, what idle power consumption do we aim for? | 19:46 |
| buZz | -10mA | 19:46 |
| buZz | :D | 19:46 |
| freemangordon | ok | 19:46 |
| buZz | hehe | 19:46 |
| buZz | would be nice, not using phone, and seeing it charge on itself | 19:46 |
| freemangordon | hehe | 19:47 |
| freemangordon | anway, setting TS to inhibited reduces power usage by 30-40 mW | 19:47 |
| Wizzup | freemangordon: well, that's good news I guess | 19:48 |
| freemangordon | mhm | 19:48 |
| freemangordon | my device is still with elogind xorg | 19:48 |
| Wizzup | I guess we have elgoind to thank for this | 19:48 |
| freemangordon | so, we have to check mce code | 19:48 |
| freemangordon | yes | 19:48 |
| freemangordon | well... | 19:48 |
| Wizzup | ridiculous :) | 19:48 |
| Wizzup | but nice | 19:48 |
| freemangordon | no, wait | 19:48 |
| freemangordon | it is xorg | 19:48 |
| freemangordon | it does not release devices when it disables them | 19:49 |
| freemangordon | elogind is not at fault here | 19:49 |
| Wizzup | well it's the code added to xorg by loginx folks | 19:49 |
| Wizzup | logind* | 19:49 |
| freemangordon | well, ok, whoever added the code | 19:49 |
| Wizzup | right | 19:49 |
| freemangordon | also, it is really hacky | 19:50 |
| freemangordon | that do some trickery with libinput fds as well | 19:50 |
| Wizzup | mhm | 19:50 |
| Wizzup | that and it's buggy | 19:50 |
| Wizzup | let's just do inhibited, I think that's what we wanted to begin with | 19:50 |
| freemangordon | but, I think we shall simply teach mce to disable input devices via sysfs | 19:50 |
| freemangordon | right | 19:50 |
| Wizzup | I wonder how mce will find the path in sysfs | 19:50 |
| freemangordon | /class/input | 19:50 |
| bencoh | from udev events | 19:51 |
| freemangordon | wait, wait | 19:51 |
| Wizzup | yeah, I think udev | 19:51 |
| freemangordon | I think it is way simpler than that | 19:51 |
| Wizzup | yes | 19:51 |
| Wizzup | there is | 19:51 |
| Wizzup | sorry | 19:51 |
| freemangordon | just inhibit all the devices that has no power and volume keys | 19:51 |
| Wizzup | /sys/class/input/event2/device/ | 19:51 |
| freemangordon | and slider as well | 19:51 |
| Wizzup | that has inhibited entry | 19:51 |
| freemangordon | yes, it has | 19:52 |
| Wizzup | freemangordon: yeah I just meant how to find the inhibited path | 19:52 |
| freemangordon | ah | 19:52 |
| Wizzup | imo we can stick the current mce logic on what to disable for now | 19:52 |
| Wizzup | like there's also the slider | 19:52 |
| Wizzup | which is not power nor volume | 19:52 |
| Wizzup | so maybe just set whatever we would normally disable to inhibited | 19:52 |
| freemangordon | yes, but it is special key as well | 19:52 |
| Wizzup | *shrug* | 19:52 |
| freemangordon | I have to look at the code | 19:53 |
| Wizzup | *nod* | 19:53 |
| freemangordon | 137610 | 19:53 |
| freemangordon | this is avg power with 2 ssh sessions | 19:53 |
| freemangordon | connected to network and wlan on | 19:54 |
| freemangordon | uvos__: ping | 20:00 |
| freemangordon | uvos__: this https://github.com/maemo-leste/mce/blob/maemo/chimaera/src/modules/x11-ctrl.c#L32 is not used, why is that? | 20:06 |
| freemangordon | also, do you want me to create another module that disables input devices through sysfs or we already have some code? | 20:07 |
| Wizzup | I would make a copy of it and call it input-ctrl or something | 20:08 |
| freemangordon | I thinkwe already have some code, I have to find it | 20:09 |
| Wizzup | I think the disabled code is probably removed | 20:09 |
| Wizzup | my guess anyway | 20:09 |
| freemangordon | :nod: | 20:19 |
| freemangordon | https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2198439.html | 21:38 |
| freemangordon | http://archive.lwn.net:8080/linux-kernel/20200608112211.12125-1-andrzej.p@collabora.com/ | 21:40 |
| uvos | freemangordon: because we must disable all input devices anyways | 23:03 |
| uvos | this is a remnant from when this module disabled touchscreens only | 23:04 |
| uvos | if you want to disable input devices via sysfs you must remember that is is a very new interface | 23:04 |
| uvos | i forget when it was added but it was added after we implmented the xinput solution | 23:05 |
| uvos | so maybe 2019 is at the earliest | 23:05 |
| uvos | so lts kernels wont have it | 23:05 |
| freemangordon | yes, it was introduced in 5.11 | 23:07 |
| uvos | we absolutly can use volume keys while the deivice is locked | 23:07 |
| uvos | this has nothing to do with this anyhow | 23:07 |
| freemangordon | but, mce from fremantle was using the same interface on n900 to disable TS | 23:07 |
| uvos | simmular interface yes | 23:08 |
| uvos | it used it for every deivce btw | 23:08 |
| uvos | not just s | 23:08 |
| uvos | ts | 23:08 |
| freemangordon | " uvos: this is a remnant from when this module disabled touchscreens only" - though so, thus the question | 23:08 |
| freemangordon | yes, I knwo | 23:08 |
| freemangordon | so, I plan to create a new module that will disable through sysfs | 23:09 |
| uvos | sure | 23:09 |
| freemangordon | do we still need x11-ctrl to disable the input devices? | 23:09 |
| uvos | depends | 23:09 |
| freemangordon | hmm? | 23:09 |
| uvos | well no yes | 23:09 |
| uvos | we do | 23:09 |
| freemangordon | why? | 23:09 |
| uvos | so you cant disable the keybaord devices (since you must be able to get power, volume etc) | 23:10 |
| uvos | but you must prevent xorg from getting any key | 23:10 |
| uvos | while the display is off | 23:10 |
| freemangordon | well, I will implement some logic there | 23:10 |
| uvos | otherwise it will enable the crtc | 23:10 |
| uvos | i would avoid implementing any logic | 23:10 |
| uvos | really | 23:11 |
| freemangordon | like, will disable only devices that does not have power, volume and slider | 23:11 |
| uvos | besides ts/keyboard | 23:11 |
| freemangordon | what other *input* devices do we want active while the device is locked? | 23:11 |
| uvos | dose userspace disableing a input device affect kernel comusmers | 23:11 |
| uvos | presumably no | 23:11 |
| freemangordon | according to docs it closes the device | 23:12 |
| freemangordon | so it might affect kernel consumers iiuc | 23:12 |
| uvos | that would be sorta bad | 23:12 |
| uvos | so i doubt it | 23:12 |
| freemangordon | why? | 23:12 |
| freemangordon | see https://lore.kernel.org/lkml/002401d96152$e5ab1f70$b1015e50$@emc.com.tw/T/ | 23:13 |
| uvos | this would mean userspace can lock out vt switching or mutch worse sysrq | 23:13 |
| freemangordon | see elan_inhibit | 23:13 |
| freemangordon | there was something in the docs about inhibited devices that remain wake-up capable | 23:14 |
| freemangordon | analogy with network devices were given | 23:14 |
| uvos | ok, point is | 23:15 |
| uvos | dont disable keyboards | 23:15 |
| uvos | for vt switching and sysrq | 23:15 |
| freemangordon | while device is locked? | 23:15 |
| uvos | yes | 23:15 |
| uvos | sure | 23:15 |
| freemangordon | this does not make any sence | 23:15 |
| uvos | yes it dose | 23:15 |
| freemangordon | not on mobile | 23:15 |
| freemangordon | for server maybe | 23:15 |
| freemangordon | but we will not inhibit on server anyway | 23:15 |
| uvos | its very usefull for debuging and it cost no power | 23:15 |
| uvos | so comeon | 23:16 |
| freemangordon | you dont; know if it costs power or not | 23:16 |
| freemangordon | in general that is | 23:16 |
| freemangordon | imagine USB keyboard attached | 23:16 |
| freemangordon | this will cost power | 23:17 |
| uvos | yes that is exactly when i want it to work | 23:17 |
| uvos | when usb keyboard is attached power is presumably less of a concern... | 23:17 |
| freemangordon | how's that? | 23:17 |
| uvos | i suggests we are close to an outlet | 23:18 |
| freemangordon | also, debuggin is not the usual usecase | 23:18 |
| uvos | or do you carry a keybord around | 23:18 |
| uvos | anyhow on d4 its functionally free | 23:18 |
| freemangordon | this is another usecase,and we have an option to not lock when connected to power supply | 23:18 |
| uvos | anyhow whatever | 23:19 |
| freemangordon | right, lets have something working | 23:19 |
| freemangordon | we can extend it afterwards | 23:19 |
| freemangordon | I will try to put some sane coding in there | 23:19 |
| uvos | anyhow it would be better if we could fix the issue in xorg/elgoind instead | 23:20 |
| freemangordon | for sure will not disable power, volume and slider devices | 23:20 |
| freemangordon | I can try to | 23:20 |
| freemangordon | the issue is in xorg | 23:20 |
| uvos | since inevitably we will have people running leste on old kernels... | 23:20 |
| freemangordon | I doubt | 23:20 |
| uvos | i mean there are people useing libhiibris | 23:20 |
| uvos | on like 3.x kernels | 23:20 |
| uvos | dunno if its worth it | 23:21 |
| uvos | depends on how mutch time it takes | 23:21 |
| freemangordon | please, don;t ask me to support this abomination, to me this is one of the reasons we still don't have foss drivers on mobile | 23:21 |
| uvos | and we cant get rid of x11-ctrl at all | 23:21 |
| freemangordon | foss gpu drivers I mean | 23:22 |
| uvos | so then we have more stuff doing the same things | 23:22 |
| uvos | effectively | 23:22 |
| uvos | freemangordon: sure | 23:22 |
| uvos | im just saying theres people doing this | 23:22 |
| uvos | with leste | 23:22 |
| freemangordon | yeah, that was my question about do we still need x11-ctrl | 23:22 |
| uvos | yes we do | 23:22 |
| uvos | as explained | 23:22 |
| freemangordon | right, but we can keep the module without loading it | 23:22 |
| uvos | no | 23:22 |
| freemangordon | ok, got it | 23:22 |
| uvos | you need it __all__ the time | 23:22 |
| uvos | since if x11 gets vol up | 23:23 |
| uvos | it will turn on the display | 23:23 |
| freemangordon | then maybe it worths trying to fix xorg | 23:23 |
| uvos | you cant configure it to not do that | 23:23 |
| freemangordon | btw, how does this play with volume keys? | 23:23 |
| uvos | they get routed around | 23:23 |
| uvos | by mce | 23:23 |
| freemangordon | ah | 23:23 |
| freemangordon | but this is a hack, no? | 23:23 |
| uvos | yes but also no | 23:24 |
| uvos | since even if you dident disable the xinput device | 23:24 |
| uvos | you would still have to route it around the tklocks exlusive keyboard grab the same way | 23:24 |
| uvos | so its no more hacky than that | 23:24 |
| freemangordon | yeah, but from the POV of users outside mce, it is a hack | 23:24 |
| uvos | no | 23:24 |
| uvos | its exactly the same | 23:24 |
| uvos | as the routing around tklock case | 23:25 |
| uvos | same dbus interface | 23:25 |
| freemangordon | ok | 23:25 |
| uvos | for consumers | 23:25 |
| freemangordon | ok, then I'll try to fix xorg first | 23:25 |
| freemangordon | because it seems more consistent | 23:25 |
| freemangordon | and there will be no 2 modules doing the same thing | 23:27 |
| freemangordon | ok, thanks | 23:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
