481737 2024-02-23 21:55:17 +0000 No visual feedback when pressing stylus buttons that emit BTN_TOOL_PEN or BTN_TOOL_RUBBER 2025-03-24 08:19:19 +0000 1 1 4 Plasma kwin input master Other Linux UNCONFIRMED https://bugs.kde.org/show_bug.cgi?id=475704 https://bugs.kde.org/show_bug.cgi?id=469232 usability NOR minor --- 0 nate kwin-bugs-null kde 0 oldest_to_newest 2291414 0 nate 2024-02-23 21:55:17 +0000 See Bug 475704 for the investigation that led here. I have a stylus with two buttons. When one button is pushed, it emits BTN_TOOL_PEN. When the other is pushed, it emits BTN_TOOL_RUBBER. In both cases, there is no visual change anywhere to suggest that the buttons are handled and recognized and actually doing anything. Thus I thought they were broken. In addition to the ability to re-bind these buttons to emit right and middle clicks (which is tracked in Bug 469232), it would be better if there was some kind of visual status change to so the user knows that their pen buttons are not broken. 2291918 1 kde 2024-02-26 09:19:40 +0000 That's on the app and kinda hard to do. These evdev events indicate not button presses but that a certain tool is in use with the device see https://www.kernel.org/doc/Documentation/input/event-codes.txt Quoting * BTN_TOOL_<name>: - These codes are used in conjunction with input trackpads, tablets, and touchscreens. These devices may be used with fingers, pens, or other tools. When an event occurs and a tool is used, the corresponding BTN_TOOL_<name> code should be set to a value of 1. When the tool is no longer interacting with the input device, the BTN_TOOL_<name> code should be reset to 0. All trackpads, tablets, and touchscreens should use at least one BTN_TOOL_<name> code when events are generated. The compositor just sees a "proximity in" event for a tool. I think it's not possible to know in general if a tool is the same physical object or not. Further reading: https://gitlab.freedesktop.org/libinput/libinput/-/issues/841#note_1699093 https://wayland.freedesktop.org/libinput/doc/1.12.0/tablet-support.html I think at some point the user should know what the buttons on their hardware do. Given that we did not receive bug reports about that so far I would make a guess that if you buy a drawing tablet that behavior would be documented and/or known by artists. 2292053 2 nate 2024-02-26 18:49:21 +0000 > I think at some point the user should know what the buttons on their hardware do. I feel called out! :D FWIW the pen in question is the one that came with my laptop, and it lives in a little garage. Hardware like this is of secondary importance compared to a standalone drawing tablet, so I think we can't expect the user to be so much of an expert in what the buttons of the pen do. Maybe Bug 469232 is enough, though. 2292201 3 kde 2024-02-27 07:39:40 +0000 > Maybe Bug 469232 is enough, though. I am not sure it's possible for these buttons because we don't actually see a button press but let's see. For exmaple I have a pen and the eraser is at the top of it (like a physical pencil with eraser). These events are generated when I turn that pen around. 2410197 4 kde 2025-03-24 08:19:19 +0000 You might be interested in https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1158