Hi James, On 10/20/23 01:22, James John wrote: > Hello Hans, > > Thank you for your support so far. I really appreciate this. > > I have always wanted to contribute to the kernel, so, this is fun for me! :) That is great and thank you for all your help with solving this. > The 2 evtest logs show that each brightness up/down keypress > gets reported twice, once by the "ACPI video bus" device and > once bythe "Asus WMI hotkeys" device. > > I do not think these are multiple events. There are different. One has the value of 0, the other has value of 1. > I am not sure what they mean. I initially thought it could be keydown and keyup events, but it is not, because > on pressing the keydown, they are still both reported. I also think the desktops handle this, maybe by filtering out > 0 values. I use KDE Plasma, and I still have 5% step despite evtest reporting these 2 events. The 1 / 0 events are indeed press / release events that is not the problem, the problem is that a single keypress reports these events on 2 different /dev/input/event# nodes. Interesting that this is not a problem for KDE, I know it is a problem for GNOME. I guess KDE may do some filtering of the duplicate events itself. > I have applied the last 2 patches. > > 1. Show no output for capslock / printscreen > > Correct. These keys are no longer captured by Asus WMI hotkeys > > 2. Show KEY_SELECTIVE_SCREENSHOT events for the > "Screen Capture" hotkey. > > I am not sure I am getting KEY_SELECTIVE_SCREENSHOT event for the "Screen Capture" hotkey. This is what I get: > Event: time 1697757579.588239, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a > Event: time 1697757579.588239, type 1 (EV_KEY), code 634 (?), value 1 > Event: time 1697757579.588239, -------------- SYN_REPORT ------------ > Event: time 1697757579.588244, type 1 (EV_KEY), code 634 (?), value 0 > Event: time 1697757579.588244, -------------- SYN_REPORT ------------ This is actually the correct output, 634 is 0x27a hexadecimal and: /usr/include/linux/input-event-codes.h : /* Select an area of screen to be copied */ #define KEY_SELECTIVE_SCREENSHOT 0x27a This is a somewhat (but not really) recent addition to the list of KEY_foo defines, so I guess you are just using a somewhat old evtest which does not know this code yet. > > And this is what I get for "Screen Capture" hotkey, from the debug you placed > [ 1096.691389] asus_wmi: raw event code 0x2a > [ 1096.691446] asus_wmi: raw event code 0xffffffffffffffff > [ 1097.982976] asus_wmi: raw event code 0x2a > [ 1097.983032] asus_wmi: raw event code 0xffffffffffffffff > > > 3. Show no output for brightness up/down, > yet brightness up/down should still work since > these are also reported by the "ACPI video bus" > > Yes, correct. No output from Asus WMI hotkeys, but there an output from Video bus Great, that means that everything works as it should now, thank you. Regards, Hans > On 18/10/2023 19:35, Hans de Goede wrote: >> Hi James, >> >> On 10/18/23 02:17, me@xxxxxxxxxxx wrote: >>> Hi Hans, >>> >>> I hope you are feeling better now. >>> Thank you so much for your support in resolving this. >>> >>>> I assume that the first "BACKLIGHT BUTTON" is the backlight DOWN button ? >>> Yes. Correct. >>> >>> >>>> 2. Can you please run: >>>> >>>> sudo evtest and then select the "ACPI video bus" (or something >>>> similar) device and see if that reports brightness up/down >>>> keypresses? And then do the same thing for the >>>> "Asus WMI hotkeys" device ? I expect the Asus WMI hotkeys >>>> device to only report brightness up keypresses (after my >>>> hwdb "fix") while I expect brightness-up events to get >>>> reported twice, by both the "ACPI video bus" device and >>>> the "Asus WMI hotkeys" device. >>> Done and attached. >>> >>>> Can you confirm this? This also means that brightness >>>> up will take bigger steps (2 steps per keypress) then >>>> brightness down, right ? >>> I am not sure I understand what you mean here. But I have attached the output here >> The 2 evtest logs show that each brightness up/down keypress >> gets reported twice, once by the "ACPI video bus" device and >> once bythe "Asus WMI hotkeys" device. >> >> This means that in e.g. GNOME the brightness will move >> up / down by 2 steps for each step, reducing the amount >> of steps from 20 to 10, or iow making each step twice >> as big. Especially at the low end of the brightness >> scale this may be an issue since steeping by 5% there >> can already make a big difference and this double >> key press reporting now changes this into stepping >> by 10% at a time. >> >>> After applying your patch, it seems to have fixed the issue! >> Thank you for all the testing and other then the double >> keypress issue + the unknown code messages everything >> now looks good! >> >> I have applied 2 more patches the first one fixes the >> unknown code messages and adds a mapping for the >> "Screen Capture" hotkey. The second test filters out >> the duplicate (duplicate with the "ACPI video bus") >> brightness up/down events. >> >> It would be great if you can add these on top of >> the previous 2 patches and then run one last >> test for me: >> >> Run evtest on the "Asus WMI hotkeys" device this should now: >> >> 1. Show no output for capslock / printscreen >> >> 2. Show KEY_SELECTIVE_SCREENSHOT events for the >> "Screen Capture" hotkey. >> >> 3. Show no output for brightness up/down, >> yet brightness up/down should still work since >> these are also reported by the "ACPI video bus" >> >> It would be great if you can confirm for each of these >> that this behaves as expected with the 2 extra patches >> applied on top of the previous patches. >> >> Regards, >> >> Hans >
