02:08 cedicactus: I already told you that to get into handling keyboard event, one needs to infer and rebuild a bare metal eve
02:08 cedicactus: ntloop
02:09 cedicactus: That is not needed on gpu only to run such code, but for only CPU mode
02:10 cedicactus: That is possible to infer it, with whatever latency, but needs to be done fast.
03:01 cedicactus: This itself is likely an interrupt request with keycode then if handled a gpio write, so the rest of the world would know, hence what to do is to expose a gpio window for the keys and redirect only these keys what application requests leaving the other untouched, and poll the gpios in bare metal mode or handle interrupts whatever, however it injects to kernel a structure of allowed keys to trace I'd suppose.
03:09 cedicactus: Likely best to do it is to look at some gpio read code, and turn it to writes to the fake window, and have it all committed by kernel with validated content a real mapping physical.
03:24 cedicactus: I was sceptical enough, but it's actually possible indeed, but harder to explain, so it needs to add some intrinsics of gpio reads to be write then map/malloc then initial read, and in theory it should do it.
08:21 MrCooper: agd5f_: simply loading the amdgpu module and bailing early in amdgpu_pci_probe takes just over 2 seconds with a Ryzen 7 1700 & SSD; executing amdgpu_init takes ~1ms
08:26 MrCooper: initializing the driver for 2 GPUs takes ~1.5 seconds
08:41 cedicactus: It's out of scope to describe how to do it, too many ways, but one offered, since for PC addressing keyboard keys are means of branching, before the jump is done or PC incremented, you ask the target PC about first answers or permutes in the machine word, and hence fifo fills those indexes into formulas, needed is to know the function of gpio read. Undoubtedly possible to function, needs little work.
09:05 colo: friend of mine has an RDNA2 GPU connected to an HDMI display; host is running arch linux (kernel 6.4) with amdgpu. if the display is not connected/turned on during POST of the machine, he cannot get the display to "light up". is there anything that can be done to make the driver try to init the output, instead of the vBIOS(?), from inside GNU/Linux?
09:25 ema: I have a similar issue with my Radeon PRO W6400: if the screen is switched off while the system is booting, switching it on later does not give any output. Only workaround is restarting the display manager
09:49 MrCooper: ema: is that with the monitor connected via DisplayPort?
09:52 ema: MrCooper: yep
09:53 ema: DisplayPort-1 specifically, not DisplayPort-0
09:54 MrCooper: some monitors appear disconnected via DisplayPort while powered down, which results in no CRTC getting enabled for it in fbcon & user space, which may result in runpm suspending the GPU, and then the driver doesn't get a hotplug notification when the monitor is turned on
13:31 ema: MrCooper: thanks, TIL
16:35 colo: MrCooper: and is there a way to "wake" the driver manually in this case?
16:36 MrCooper: anything which triggers a resume of the GPU
16:37 colo: unfortunately, I know 0 ways to do that - can you maybe point me towards any one? :)
16:43 MrCooper: e.g. running any application which opens a DRM device, or maybe accessing certain files under /sys
16:44 MrCooper: not sure there's any way without remote access to the machine though