<pq>
things like "are you sure that policy is always correct" and "what about physical seats which are purely a userspace conccept"
<karolherbst>
yeah... not saying this is the perfect solution, but I think we need something like this
<karolherbst>
one way or the other
<pq>
we already have the physical seats problem with the kernel VT
<pq>
as in, if you happen to have a second physical seat, while the kernel VT is active on the primary physical seat, all keyboard events on the second seat to go the VT as well.
<pq>
I'm not against the idea of input events triggering ramp-up in DRM, but I do think it needs to be userspace configurable policy and not hardcoded in kernel.
<karolherbst>
ah yeah, sounds like a solid idea actually
<karolherbst>
and I would also bring up, why dri-devel wasn'et CCed :D
<karolherbst>
*wasn't
<karolherbst>
at least drm-misc maintainers were... and dave
rasterman has joined #dri-devel
<emersion>
oh, i missed it as well :(
<emersion>
agree with pq
<karolherbst>
good that I brought it up then I guess
<karolherbst>
ohh wait
<karolherbst>
that was in RH internally..
<pq>
karolherbst, actually I noticed it from Phoronix :-P
<karolherbst>
me as well
<pq>
oh, and another question: "if userspace has not opened the input device, will it still result in KMS/GPU ramp-up?"
<karolherbst>
pq: I suspect that this isn't really a likely use case or one that matters, because... can you think about any reason where somebody is generating those events without anything ever happening?
<pq>
karolherbst, sure, anything with an accelerometer
<pq>
like a game controller
<karolherbst>
but userspace would still open the device, no?
<pq>
audio plugs often show up as input devices too, I think
<karolherbst>
ohh wait
<karolherbst>
you mean you just don't have any game, but the gamepad continues generating events for whatever reason
<pq>
no, I mean the case when no app is using the controller
<karolherbst>
yeah...
<pq>
yup
<karolherbst>
right
<pq>
like, does DRM hooking up to the input device work as if userspace had actually opened it and subscribed to event?
<karolherbst>
honestly, I have no idea what a good policiy here should look like, and maybe some just saw the benefits, but didn't think about the regression it might cause e.g. on laptops
<pq>
no idea how it works
<pq>
I'm also not sure if joystic analog axes would be sending continuous or spurious events all the time. Depends on the joystick quality, too.
<karolherbst>
yeah, they usually don't
<karolherbst>
those are usually polled anyway
<karolherbst>
afaik
<pq>
no, I don't think so
<pq>
SDL2 may be polling, but evdev is not a polling interface
<pq>
*SDL2 API
<karolherbst>
sadly "cat /dev/input/*" doesn't do antyhing anymore... so can't really tell
<karolherbst>
mhh
<karolherbst>
right...
<karolherbst>
let's see..
<HdkR>
Many people also use gamepads that don't center the joysticks properly so they are always shifting by 1-2 values anyway
<HdkR>
Old Xbox 360 controllers being notorious for this
<clever>
karolherbst: try running evtest?
<pq>
at USB level I'd expect enable/disable commands to a joystick and when it's enabled (or simply opened), it'll send every time when the value changes (e.g. noise) if not at a constant rate.
<karolherbst>
I have a xbox and nintendo switch controller.. so let's see what those do
<karolherbst>
ahh yeah...
<karolherbst>
the switch one spams
<karolherbst>
pq: the xbox one does not
<karolherbst>
but the switch one could spam, because I am not on 5.16 with the proper driver...
<karolherbst>
at least the xbox one is dead silent as long as I don't use it
<clever>
karolherbst: i think if the input device isnt open, then the usb link will be dead
<clever>
you can confirm that with `modprobe usbmon ; wireshark`
<karolherbst>
ohhh.. right...
<karolherbst>
let me quit steam
<karolherbst>
mhhh
<pq>
but does DRM hooking up to the input device "open" it?
<karolherbst>
now the switch one doesn't do anything...
<karolherbst>
ehh.. I won't try out this dkms-hid-nintendo thing now... :D
<karolherbst>
pq: I guess the answers are inside the patches
<karolherbst>
pq: it calls input_open_device
<karolherbst>
from inside drm
<karolherbst>
mhh
<karolherbst>
it even has handling for joysticks...
<pq>
karolherbst, one could also point to the troubles that libinput needs to go through with the udev database to figure out what an input device is.
<emersion>
also there are some input devices the kernel isn't aware of
<emersion>
e.g. with remote desktop protocols
<karolherbst>
emersion: next step: listen to network traffig :D
<emersion>
ahah
<karolherbst>
*traffic
<emersion>
with deep packet inspection to decode the protocols ofc
<pq>
I think the simplest thing would be to just let userspace (display server) register input devices one by one with a specific DRM device to trigger ramp-up.
<karolherbst>
that goes without saying
<karolherbst>
pq: yeah
<karolherbst>
but there is another issue
<karolherbst>
sometimes applications also want to trigger it
<emersion>
yeah
<karolherbst>
like.. think about applications just doing cursor blinking or something :D
<karolherbst>
although I'd argue you could/want to suspend such things
<karolherbst>
no useless blinking if PSR is on
<pq>
right, that's a much larger scope - so is the question here that input -> ramp-up must be shortcircuited inside the kernel, or is a userspace roundtrip affordable?
<pq>
if it must be acted on purely in-kernel, then I think userspace should explicitly register input devices with specific DRM devices.
<emersion>
kernel needs new frames anyways right?
<emersion>
so needs user-space to perform atomic commits
<pq>
emersion, I don't think so.
<pq>
emersion, the whole point is to ramp up hw *before* userspace manages to make commits, I believe.
<karolherbst>
yeah..
<karolherbst>
it sounds like PSR is apparently some high latency operation and you want to "quit" PSR asap
<emersion>
ok
<pq>
PSR is just one thing, too, GPU clocking is another
<karolherbst>
right
<karolherbst>
but I think this is limited to PSR atm
<emersion>
would be nice to be able to register any FD then
<pq>
yes, the patches are about PSR, but GPUs were mentioned too
<karolherbst>
"10s of milliseconds for a panel to exit self-refresh"
<emersion>
so the compositor could choose to send an input FD, or a libinput epoll FD, or a custom epoll FD
<pq>
emersion, now that's a neat idea
<karolherbst>
yeah, I think we have to let userspace decide what it cares about and what should trigger those ramp ups
<karolherbst>
I am not even sold on the _any_ user input should do it
<karolherbst>
like just because you move your cursor doesn't mean you want max clocks out of the sudden
<karolherbst>
normally you only want it to happen right before heavy animations
<karolherbst>
so a compositor could say "I will start something heavy, so please clock up to the max already"
<emersion>
right, i don't really like the idea of hard-coding policy in the kernel
<karolherbst>
I think the idea was that userspace wouldn't have to care, because if you do it properly, you have to implement such policies into every compositor
<emersion>
somewhat related is the dma fence deadlines RFC
<karolherbst>
because I honestly don't see a good way except doing explicit API calls inside compositors
<karolherbst>
heck.. I have a 2x 4K setup here and normally do get a somewhat smooth experience I have to keep CPU clocks high...
<karolherbst>
because the ramp up is just too slow
<karolherbst>
but the problem isn't the GPU or CPU
<karolherbst>
but they each other preventing them from going max in a split
<karolherbst>
so the CPU increases a little as the GL driver puts some load, but not too much, because the GPU is not fast enough yet, so the GPU increases clocks a little, but then the CPU is too slow :)
gouchi has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
lemonzest has joined #dri-devel
Company has joined #dri-devel
lanodan_ has left #dri-devel [#dri-devel]
lanodan_ has joined #dri-devel
<FLHerne>
karolherbst: For extreme laptop regression, I have my old Thinkpad set up with the HDD accelerometer as a joystick so I can play SuperTuxKart by tilting the laptop
<karolherbst>
:D
<FLHerne>
I think this idea would probably make the GPU run at full tilt all the time
<karolherbst>
FLHerne: I think the idea isn't to run the GPU at full clocks, but you have this annoying issue that if your GPU is at lowest clocks, it doesn't ramp up quickly enough for spikey loads
gawin has joined #dri-devel
<ishitatsuyuki>
trying to debug an issue where OBS inside xpra (using llvmpipe) fails to update captured window (the first frame captured stays there until reconfiguration). there's evidently some way to get screen capture work (because xpra itself is basically a screen capturer), and I'm clueless right now why OBS is broken in that way
<ishitatsuyuki>
to make some comparisons I also tried using Chromium screen capture which works flawlessly. one thing that Chromium and xpra uses in common is XShmGetImage, while OBS uses glXBindTexImageEXT on the pixmap it requested and blits it using GL
<ishitatsuyuki>
if someone know about this bug or has any suggestions about where the problem might be, please let me know
rando25892 has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
and I immediately figured out LMAO
<ishitatsuyuki>
apparently the software version of glXBindTexImageEXT does a blit and everything ends up getting done on the copied version
<ishitatsuyuki>
changed it to call glXBindTexImageEXT before every draw call and it's now working
<MrCooper>
yes, that's required by GLX_EXT_texture_from_pixmap (just happens to work without on some setups)
<ishitatsuyuki>
oh thanks for confirming, now I can confidently post a patch to OBS
rando25892 has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pekkari has quit [Quit: Konversation terminated!]
pcercuei has joined #dri-devel
mclasen has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
flacks has joined #dri-devel
mclasen has quit [Remote host closed the connection]
mclasen has joined #dri-devel
mclasen has quit [Remote host closed the connection]
mclasen has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
X-Scale` has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]