mce: switch from dpms to drm blanking

[MerlijnWajer]

Long story short, pressing the volume keys wakes up X, unblanks the display (even with the brightness at 0), which causes significant power drain.

Likely the best way to deal with this is to disable dpms on the X server, and have mce perform fb blank (it already does) and drm blank (it doesn't do this yet). This way input will still go to X, but the display should not turn on.

I think we can just remove all the DPMS code from mce in favour of this, but maybe we want to at least keep it around somewhere.

14:36 < Wizzup> uvos: so I think all apps get their keys via X
14:36 < Wizzup> so disabling the volume keys / device in X is not an option
14:36 < Wizzup> also because we can't rely on those being exposed as a separate device
14:39 < Wizzup> and yeah, I just reproduced that too
14:41 < Wizzup> looks like tklock sends signals for these keys
14:41 < Wizzup> signal time=1593866429.740132 sender=:1.21 -> destination=(null destination) serial=121 path=/com/nokia/tklock/signal;
                interface=com.nokia.tklock.signal; member=mm_key_press uint32 123 uint32 269025043
14:41 < Wizzup> osso-systemui-tklock/gp-tklock.c:242
14:43 < Wizzup> I think pressing the buttons will at least cause some temporary wakeup, we just need to figure out how to put the device back to sleep
14:43 < uvos> "so disabling the volume keys / device in X is not an option" i would disable every device
14:43 < Wizzup> what if the power button is on the same device as the volume keys and keyboard?
14:44 < uvos> Wizzup: mce just kicks xorg out of dpms idle state
14:44 < Wizzup> it's not mce
14:44 < uvos> Wizzup: xorg dosent need to see the power button then
14:44 < Wizzup> what makes you say it's mce?
14:44 < uvos> Wizzup: or tklock or whatever
14:44 < Wizzup> oh
14:44 < Wizzup> I see
14:44 < uvos> Wizzup: mce handles input via evdev allready
14:45 < uvos> Wizzup: so i could kick x
14:45 < uvos> Wizzup: thats why i say x
14:45 < Wizzup> so if mce wakes up X for a single volume raise, what's next?
14:45 < uvos> Wizzup: it dosent
14:45 < Wizzup> ?
14:45 < uvos> Wizzup: volume is handled by a deamon that reads evdev directly and adjusts pulse/alsa
14:45 < uvos> Wizzup: x is not used
14:46 < Wizzup> this is not how it works
14:46 < uvos> Wizzup: right
14:46 < Wizzup> maemo-statusmenu-volume $ grep -r KEYCODE_F7 .
14:46 < Wizzup> ./src/item.c:#define KEYCODE_F7 (XKeysymToKeycode(GDK_DISPLAY(), XK_F7))
14:46 < uvos> Wizzup: but this is how it could owrk
14:46 < uvos> Wizzup: alteratively we write a x module
14:47 < uvos> Wizzup: xf86-input-maemo that filters inputs maybe prevents dpms from getting events (no clue if this is possible)
14:47 < Wizzup> can't mce monitor input devices, and if it knows the device is asleep, call https://linux.die.net/man/3/dpmsinfo and suspend X again?
14:47 < Entitlement> Wizzup - [ dpmsinfo(3) - Linux man page ]
14:48 < Wizzup> I suppose it's not preventing X from waking up, but I don't think this is such a bad thing per se
14:48 < uvos> Wizzup: thats spining up x every time the volume key get presst will be a huge  power drain
14:48 < Wizzup> I mean, not in the normal use case :)
14:48 < uvos> Wizzup: monitoring evdev the volume key gets pressed every couple of seconds while walking
14:48 < uvos> Wizzup: in my pocket
14:48 < uvos> Wizzup: i dont think its viable
14:49 < uvos> Wizzup: we could also fix x
14:49 < uvos> Wizzup: many people complain that they cant make x not wake up on mouse input on the 'net
14:49 < Wizzup> they just need to call xinput disable
14:49 < uvos> Wizzup: so a new feature for the dpms module might be well recived
14:50 < uvos> Wizzup: sortof
14:50 < uvos> Wizzup: that only works if you want to disable all input from a device
14:50 < Wizzup> so in the case where you are continously pressing the volume button in your pocket
14:50 < Wizzup> that will still cause all these wakeups
14:51 < Wizzup> just not in X, but by keeping the device active
14:51 < uvos> Wizzup: but x takes a particularly long time to do dpms
14:51 < uvos> so waht problem do you have with: x gets no input while the display is off, volume is handled outside of x?
14:51 < Wizzup> so I think we are looking at two different problems: (1) if X gets woken up by a legitimate volume key press, it should go back into idle mode (2) we
                need to think about trigger happy buttons
14:52 < uvos> the main problem is that waking up x is tied to wakeing up the display
14:52 < Wizzup> uvos: X is the input multiplexer for the linux desktop
14:52 < uvos> i dont care if x recives events while the display is of
14:52 < Wizzup> I don't think we need a lot more daemons all doing the same
14:53 < Wizzup> s/shortcuts/key presses/
14:53 < uvos> Wizzup: sure it would still work, but only while the display is on
14:53 < uvos> Wizzup: the whole thing with x keeping the input open while the diplay is off is bad anyways
14:54 < uvos> Wizzup: since random hardware could have a keyboard that cosumes a lot of power too
14:54 < uvos> mce could selectively keep only devices with key_power and volume keys open
14:55 < Wizzup> say a device doesn't have a sliding keyboard, but an always visible keyboard, would a keypress on that keyboard not wake up the device?
14:55 < uvos> so imho we have 2 options:
14:55 < uvos> Wizzup: maybe but if it takes 50mW the user should have a say..
14:55 < uvos> Wizzup: also on a blackberry type device: no
14:56 < uvos> 1. we fix x so that waking up x for events is not tied wakeing up the display by force
14:56 < uvos> 2. we cut x off
14:57 < Wizzup> I would like the volume path to still go through X somehow
14:57 < Wizzup> but if mce enables the device for X for a bit once it receives the key, it's already too late
14:58 < uvos> right
14:58 < uvos> so fremantle probubly has a patch that dose 1
14:59 < uvos> right?
14:59 < Wizzup> I don't know what fremantle does, it might not even use dpms
14:59 < uvos> k
14:59 < uvos> we could go that rout too
14:59 < uvos> and use randr
14:59 < uvos> but that opens antohter can of bugs
14:59 < Wizzup> no, that is not ok
15:00 < Wizzup> very few programs like all displays being gone
15:00 < uvos> yeah
15:00 < uvos> i thin 2 is the most realistic option...
15:00 < Wizzup> I wonder if the XScreenSaver API can be used here
15:00 < uvos> *think
15:00 < uvos> no
15:01 < uvos> dosent help us
15:01 < uvos> its used in combination with blanking the display by drawing a black rectange
15:01 < uvos> witch worked fine in crt days
15:02 < Wizzup> we could also set a very short dpms timeout for X when the device is locked
15:02 < Wizzup> hm, probably a hack
15:04  * Wizzup is looking at xorg-server/mi/mieq.c
15:04 < Wizzup> ideally
15:05 < Wizzup> s/ideally//
15:06 -!- jonsger [~Icedove@aftr-88-152-184-127.unity-media.net] has joined #maemo-leste
15:06 < B0075> 20
15:06 < B0075> lol
15:06 < Wizzup> mhm?
15:11 -!- jonsger [~Icedove@aftr-88-152-184-127.unity-media.net] has quit [Ping timeout: 264 seconds]
15:15 < Wizzup> uvos: fremantle has this in serverflags:
15:15 < Wizzup> IOptionI"OffTime"I"0"
15:15 < Wizzup> IOptionI"StandbyTime"I"0"
15:15 < Wizzup> IOptionI"SuspendTime"I"0"
15:16 < Wizzup> I don't know if they ever really 'disable' the display as such, or idle it some other way
15:17 < Wizzup> it could be that FB_BLANK_POWERDOWN somehow doesn't care if keys are pressed or not
15:18 < Wizzup> in which case X won't even wake up the displa
15:18 < Wizzup> y
15:18 < uvos> maybe kms can do that too...
15:18 < uvos> idk
15:19 < uvos> we could just disable dpms
15:19 < uvos> and do the syscalls ourselves
15:19 < Wizzup> yes, if there is a way we can do that, then that's fine, then we can disable dpms.
15:19 < uvos> sure
15:19 < uvos> x calls some dpms syscalls we can call those
15:19 < uvos> why not
15:21 < uvos> what works right now
15:21 < uvos> is disabeling xorgs dpms
15:22 < uvos> and writing to /sys/class/drm/card1-DSI-1/dpms
15:22 < Wizzup> https://paste.villavu.com/show/olabTvWXCgqDbrRMsFVVoF9KJFcB8548f5HfDkr5/
15:22 < Entitlement> Wizzup - [ Kirby 2015 ]
15:22 < Wizzup> sorry, raw here https://paste.villavu.com/raw/olabTvWXCgqDbrRMsFVVoF9KJFcB8548f5HfDkr5/
15:22 < Wizzup> see [pid  2282] ioctl(12, DRM_IOCTL_MODE_GETPROPERTY, 0xbecd7940) = 0
15:23 < Wizzup> uvos: this sounds fine to me - agreed?
15:23 < uvos> yes
15:23 < uvos> i dont like it because it makes the device more maemo dependant
15:23 < Wizzup> so then we will replace the modules/display.c code that uses X11 DPMS with old school fb blank calls (already there) + drm dpms
15:23 < uvos> but its the best of bad options
15:24 < Wizzup> merlijn@gentoo-x230 /usr/include $ grep -r  DRM_IOCTL_MODE_SETPROPERTY .
15:24 < Wizzup> ./drm/drm.h:#define DRM_IOCTL_MODE_SETPROPERTYIDRM_IOWR(0xAB, struct drm_mode_connector_set_property)
15:24 < Wizzup> (love gentoo for always having all headers I ever need, right there)
15:24 < Wizzup> do you want to code this, or shall I do it?
15:24 < uvos> same with artch
15:24 < uvos> *arch
15:24 < Wizzup> :)
15:24 < uvos> i can to it
15:24 < uvos> but it will take some time
15:24 < uvos> before it find time
15:25 < uvos> ill just tell you when i start working on it
15:25 < uvos> and vice versa
15:26 < uvos> whomever starts first dose it :P
15:27 < Wizzup> ok
15:27 < Wizzup> I am planning to do more pulseaudio today + volume applet
15:27 < Wizzup> so it's funny timing
15:27 < Wizzup> honestly this should be pretty simple
15:28 < Wizzup> https://waynewolf.github.io/2012/09/05/libdrm-samples/
15:28 < Entitlement> Wizzup - [ libdrm samples | Wayne's Blog ]
15:29 < Wizzup> just open all /dev/dri/card*
15:29 < Wizzup> hm..
15:29 < Wizzup> ok, I'll do more audio first, then look at this
15:29 < Wizzup> but let me know if you do

[MerlijnWajer]

We'll also need to change the X server flags, though.

[MerlijnWajer]

FYI: https://lists.x.org/archives/xorg-devel/2020-August/058599.html

[IMbackK]

no longer relevant