| sicelo | what full duplex is arno11 referring to? | 08:37 |
|---|---|---|
| freemangordon | both parties able to be heard I guess | 08:37 |
| sicelo | ah, with the voice calls, thanks | 08:37 |
| uvos | heh touchscreen buttons just got some commercial backing some person from Wolfvision GmbH wants to use it and try submitting it upstream again | 10:20 |
| uvos | maybe the input maintianers will care enough to at least look at the thing now | 10:20 |
| freemangordon | uvos: yeah, looks like what happened to input 'inhibit' | 11:23 |
| freemangordon | uvos: if mce modue opens some evdev device, does it somehow register that? | 11:33 |
| freemangordon | or, what about if input-ctrl enumerates all opened fds in /proc/$(pidof mce) and does not inhibit those? | 11:34 |
| freemangordon | ok, seems we have pointer_dev_list and keyboard_dev_list | 11:37 |
| uvos__ | right | 11:42 |
| uvos__ | i think pointer_dev_list would be fine as a first aproximation | 11:43 |
| uvos__ | these are the devices mce will itself disconnect from during display off | 11:43 |
| uvos__ | but using that directly from a module is ugly | 11:44 |
| freemangordon | uvos__: so, lets confirm - my idea is to have 2 more helper functions in event-input.c that will give access to either pointer_dev_list and keyboard_dev_list directly or to some copy of those lists | 13:23 |
| freemangordon | then every module will be able to enumerate input devices currently opened by mce and do whatever it wants to with this information | 13:24 |
| freemangordon | in particular - input-ctrl will inhibit everything that is not in keyboard_dev_list on display off | 13:24 |
| uvos__ | sure | 13:24 |
| uvos__ | just dont access the global from the module directly | 13:25 |
| uvos__ | also lock not display off | 13:26 |
| uvos__ | and be carefull about the one-click mess | 13:27 |
| freemangordon | sure (direct access) | 13:27 |
| freemangordon | can;t parse - why on lock? | 13:27 |
| uvos__ | the ts must remain active while the display is off but the deivce is not locked | 13:27 |
| freemangordon | f tklock is enabled, we don;t want TS to be inhibited | 13:27 |
| uvos__ | otherwise touch wont reset the timers | 13:27 |
| freemangordon | ok, I'll do what x11-ctrl does | 13:28 |
| uvos__ | no no | 13:28 |
| uvos__ | it dosent do this | 13:28 |
| freemangordon | it does | 13:28 |
| uvos__ | no | 13:28 |
| freemangordon | a | 13:28 |
| freemangordon | ah, I see | 13:28 |
| freemangordon | we disable with xorg, but not with mce | 13:28 |
| uvos__ | because mce needs to get ts while display is off but not locked | 13:28 |
| freemangordon | mhm | 13:28 |
| uvos__ | but xorg dosent | 13:28 |
| uvos__ | right | 13:28 |
| freemangordon | right | 13:28 |
| freemangordon | got it | 13:28 |
| freemangordon | ok, I'll see when current code suspends TS | 13:29 |
| uvos__ | right | 13:29 |
| freemangordon | ok | 13:29 |
| freemangordon | uvos__: touchscreen_suspend_pipe? | 13:37 |
| uvos__ | right | 13:39 |
| uvos__ | altho this is a big mess in lock-tklock.c | 13:41 |
| uvos__ | really both event-input should be able to figure it out itself based on the modes, but yes thats how it currently works | 13:42 |
| freemangordon | to me this is really better to have one place only that makes those decisions | 13:56 |
| freemangordon | otherwise we risk to be inconsistent (if every module draws its own conclusions) | 13:56 |
| freemangordon | nto to say the duplication of code | 13:57 |
| freemangordon | s/say/mention/ | 13:57 |
| sicelo | do we ever want to support tap-to-wake, like on N9/Harmattan? 😃 | 14:01 |
| sicelo | in that case i suppose ts would need to be enabled even when display off, or even when locked | 14:02 |
| uvos__ | sicelo: well our current hw is very bad at this, as the power consumption of th ts is immense | 14:14 |
| uvos__ | mapphone ts has a special mode for this, but in my expierance it dosnt work so great (and still uses quite a bit of power) | 14:14 |
| uvos__ | so currently i would say we dont have any plans for tap to wake | 14:15 |
| uvos__ | but yeah having it in one place would be good | 14:15 |
| uvos__ | unfortionatly the suspention descisions are spread across tklock.c and are duplicated in lock-generic.c and are sotra repeaded agian in x11-ctrl | 14:16 |
| uvos__ | anyhow yes use touchscreen_suspend_pipe, i take issue with its implementation on the sender end, its fine in principal | 14:19 |
| uvos__ | and on the reciveing end | 14:19 |
| uvos__ | imo you can also add the inhibiting to event-input instead of some special module if you like, as long as you provide a fallback path (to doing nothing) and a frendly info print if the kernel is to old. | 14:20 |
| freemangordon | uvos__: My gut feeling tells me a module is better | 17:54 |
| sicelo | Wizzup: n900's charge full 'issue' is not in kernel. it does emit POWER_SUPPLY_CAPACITY_LEVEL=Full at the right time. however upower doesn't use this property | 21:55 |
| Wizzup | sicelo: that's dumb, thanks for checking | 21:56 |
| Wizzup | maybe we are missing a patch from spinal | 21:56 |
| sicelo | are you sure it did work at some point in Leste? | 21:58 |
| sicelo | re: upower - some months ago, i submitted https://gitlab.freedesktop.org/upower/upower/-/issues/218 | 21:58 |
| sicelo | i wish upower would properly support N900 and Droid 4 out of the box | 21:59 |
| Wizzup | sicelo: yes I think it did in leste | 22:09 |
| Oksanaa | What are the chances of Pine phone with Maemo Leste being capable of running the Android app? https://www.flir.com/support-center/flir-one/flir-one-device-compatibility/ | 22:10 |
| Wizzup | sicelo: no feedback huh :( | 22:10 |
| Oksanaa | Requirement: arm64-v8a. Pinephone: 64 bit, is that alright? | 22:11 |
| Oksanaa | Requirement: GPS and location. Pinephone: GPS might be working. | 22:12 |
| Oksanaa | Requirement: microphone. Pinephone: audio might be working. | 22:12 |
| Oksanaa | Requirement: USB OTG. Pinephone: Untested. | 22:13 |
| uvos | Oksanaa: anbox works on pp | 22:47 |
| uvos | but i doubt a ap that interfaces with custom hw will work | 22:47 |
| xmn | So does waydroid | 22:47 |
| uvos | no on leste | 22:47 |
| uvos | *not | 22:47 |
| xmn | I saw anbox on leste. But don't remember how well it actually worked. | 22:48 |
| Wizzup | anbox is slow | 23:12 |
| Wizzup | waydroid is kinda slow too, but not -that- slow | 23:12 |
| freemangordon | ugh... Registering /dev/input/event1 as keyboard fd: -1 | 23:40 |
| freemangordon | event1 -> ../../devices/platform/mapphone_touchscreen/input/input2/event1 | 23:40 |
| freemangordon | uvos: is that ok? | 23:40 |
| freemangordon | like, this seems to keep TS enable, no? | 23:41 |
| Wizzup | maybe this is ts buttons? | 23:41 |
| freemangordon | yes | 23:41 |
| freemangordon | but is still TS | 23:42 |
| freemangordon | hmm | 23:42 |
| freemangordon | "mce: event-input: unbinding 2 touchscreen devices" | 23:42 |
| freemangordon | there is more that's going on there it seems | 23:42 |
| uvos | yeah thats correct | 23:42 |
| uvos | mapphones have 2 ts | 23:42 |
| freemangordon | right | 23:43 |
| uvos | beacause of the filtered touchscreen | 23:43 |
| Wizzup | right, but it's seen as keyboard | 23:43 |
| freemangordon | but mce assume buttons as KBD, no? | 23:43 |
| uvos | no | 23:43 |
| uvos | touchscreen buttons creates 2 devices | 23:43 |
| uvos | one with the touch events with those filtered that land on the buttons | 23:43 |
| uvos | this one is reccognized as a ts | 23:43 |
| uvos | and one with just the buttons | 23:44 |
| uvos | this one is recognized as a keyboard | 23:44 |
| freemangordon | right | 23:44 |
| freemangordon | but it is still TS | 23:44 |
| freemangordon | lrwxrwxrwx 1 root root 0 Apr 2 16:51 event1 -> ../../devices/platform/mapphone_touchscreen/input/input2/event1 | 23:44 |
| freemangordon | lrwxrwxrwx 1 root root 0 Apr 2 16:51 event2 -> ../../devices/platform/mapphone_touchscreen/input/input1/event2 | 23:44 |
| uvos | nope | 23:44 |
| uvos | its irellivant for purposes of pm | 23:44 |
| freemangordon | ok | 23:44 |
| freemangordon | uvos: so, is this https://pastebin.com/yBp2BpGm ok then? | 23:45 |
| uvos | yes keeping the ts-buttons buttons event device open costs zero power | 23:46 |
| freemangordon | ok | 23:46 |
| freemangordon | I will try to confirm | 23:46 |
| uvos | i mean i know how my own driver works :P | 23:49 |
| freemangordon | sure, but I am seeing too high power usage with only TS inhibited | 23:49 |
| freemangordon | so just want to verify it is not caused by TS buttons being active | 23:51 |
| freemangordon | uvos: 146453 for power_avg, 2 ssh sessions via wifi. is that ok? | 23:56 |
| freemangordon | lemme check when connected to gsm | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!