<freemangordon>
both parties able to be heard I guess
<sicelo>
ah, with the voice calls, thanks
macros_2ndPC has joined #maemo-leste
macros_ has quit [Ping timeout: 248 seconds]
Twig has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
heh touchscreen buttons just got some commercial backing some person from Wolfvision GmbH wants to use it and try submitting it upstream again
<uvos>
maybe the input maintianers will care enough to at least look at the thing now
pere_ has quit [Ping timeout: 276 seconds]
<freemangordon>
uvos: yeah, looks like what happened to input 'inhibit'
<freemangordon>
uvos: if mce modue opens some evdev device, does it somehow register that?
<freemangordon>
or, what about if input-ctrl enumerates all opened fds in /proc/$(pidof mce) and does not inhibit those?
<freemangordon>
ok, seems we have pointer_dev_list and keyboard_dev_list
uvos__ has joined #maemo-leste
<uvos__>
right
<uvos__>
i think pointer_dev_list would be fine as a first aproximation
<uvos__>
these are the devices mce will itself disconnect from during display off
<uvos__>
but using that directly from a module is ugly
Twig has quit [Ping timeout: 276 seconds]
Twig has joined #maemo-leste
pere has joined #maemo-leste
pere has quit [Ping timeout: 248 seconds]
uvos__ has quit [Ping timeout: 264 seconds]
uvos__ has joined #maemo-leste
pere has joined #maemo-leste
Daanct12 has joined #maemo-leste
pere has quit [Ping timeout: 255 seconds]
<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
<freemangordon>
then every module will be able to enumerate input devices currently opened by mce and do whatever it wants to with this information
<freemangordon>
in particular - input-ctrl will inhibit everything that is not in keyboard_dev_list on display off
<uvos__>
sure
<uvos__>
just dont access the global from the module directly
<uvos__>
also lock not display off
<uvos__>
and be carefull about the one-click mess
<freemangordon>
sure (direct access)
<freemangordon>
can;t parse - why on lock?
<uvos__>
the ts must remain active while the display is off but the deivce is not locked
<freemangordon>
f tklock is enabled, we don;t want TS to be inhibited
<uvos__>
otherwise touch wont reset the timers
<freemangordon>
ok, I'll do what x11-ctrl does
<uvos__>
no no
<uvos__>
it dosent do this
<freemangordon>
it does
<uvos__>
no
<freemangordon>
a
<freemangordon>
ah, I see
<freemangordon>
we disable with xorg, but not with mce
<uvos__>
because mce needs to get ts while display is off but not locked
<freemangordon>
mhm
<uvos__>
but xorg dosent
<uvos__>
right
<freemangordon>
right
<freemangordon>
got it
<freemangordon>
ok, I'll see when current code suspends TS
<uvos__>
right
<freemangordon>
ok
<freemangordon>
uvos__: touchscreen_suspend_pipe?
<uvos__>
right
<uvos__>
altho this is a big mess in lock-tklock.c
<uvos__>
really both event-input should be able to figure it out itself based on the modes, but yes thats how it currently works
<freemangordon>
to me this is really better to have one place only that makes those decisions
<freemangordon>
otherwise we risk to be inconsistent (if every module draws its own conclusions)
<freemangordon>
nto to say the duplication of code
<freemangordon>
s/say/mention/
<sicelo>
do we ever want to support tap-to-wake, like on N9/Harmattan? 😃
<sicelo>
in that case i suppose ts would need to be enabled even when display off, or even when locked
uvos__ has quit [Ping timeout: 250 seconds]
uvos__ has joined #maemo-leste
<uvos__>
sicelo: well our current hw is very bad at this, as the power consumption of th ts is immense
<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)
<uvos__>
so currently i would say we dont have any plans for tap to wake
<uvos__>
but yeah having it in one place would be good
<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
<uvos__>
anyhow yes use touchscreen_suspend_pipe, i take issue with its implementation on the sender end, its fine in principal
<uvos__>
and on the reciveing end
<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.
pere has joined #maemo-leste
Daanct12 has quit [Ping timeout: 264 seconds]
elastic_dog has quit [Read error: Connection reset by peer]
Daanct12 has joined #maemo-leste
elastic_dog has joined #maemo-leste
pere has quit [Ping timeout: 250 seconds]
Daanct12 has quit [Ping timeout: 265 seconds]
xmn has joined #maemo-leste
pere has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
pere has quit [Ping timeout: 248 seconds]
xmn has quit [Ping timeout: 248 seconds]
xmn has joined #maemo-leste
uvos__ has quit [Ping timeout: 246 seconds]
uvos__ has joined #maemo-leste
xmn has quit [Ping timeout: 250 seconds]
norayr has joined #maemo-leste
xmn has joined #maemo-leste
<freemangordon>
uvos__: My gut feeling tells me a module is better
<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
<Wizzup>
sicelo: that's dumb, thanks for checking
<Wizzup>
maybe we are missing a patch from spinal
<sicelo>
are you sure it did work at some point in Leste?