Created attachment 1933027 [details] The dmesg.txt file. 1. Please describe the problem: Sensepoint (or pointing stick) is not working 2. What is the Version-Release number of the kernel: kernel-6.0.12-300.fc37.x86_64 kernel-6.0.12-300.2142574_2.fc37.x86_64.rpm (test kernel that fixes Bug 2142574) 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : No 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Turning on the computer and booting fedora 37. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: I did not try, because I use a the test kernel that fixes a previous bug. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag.
Edgar, thank you for filing a new bug report for this. I have asked a colleague to take a look at this.
Thanks for the bug report. I can see 2 potential input devices that could be related to you trackstick: [ 1.600824] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 [ 2.872792] input: ASUE1201:00 04F3:3148 Mouse as /devices/pci0000:00/0000:00:19.0/i2c_designware.2/i2c-2/i2c-ASUE1201:00/0018:04F3:3148.0002/input/input6 The first one being the PS/2 keyboard (they might have wired the trackstick through it), and the second being a dedicated one, attached to the touchpad (which would make sense). But we first need to know if we get the events. Can you run `sudo hid-recorder` from the package hid-replay, and select the ASUE1201:00 node (hidraw1 according to your dmesg), move the trackstick a bit and attach the full log here (be sure to not touch the touchpad)? If we don't get events from it, we'll need some debug info from the PS/2 with ps2record, but I don't think we have a fedora package for it.
Created attachment 1933085 [details] The generated output running hid-recorder. Attached please find the output of the hid-recorder.
Created attachment 1933087 [details] proposed patch Thanks. So it turns out that the report descriptor contains 2 mice, and I suspect hid-multiotuch simply ignores the second one. And of course, the second one is used by your trackstick. So, we need to force the HID quirk HID_QUIRK_MULTI_INPUT for this device, and this can be achieved by setting the class MT_CLS_WIN_8_FORCE_MULTI_INPUT to your device. Attached a proposed patch. Please test it if you can.
Thank you for your quick answer and help. Could you please help me with a proper link or description about the method you recommend as the best way to apply the patch?
Hi Edgar, Benjamin, Benjamin thank you for your help and the patch. Edgar, as with the keyboard issue I have just started a test kernel build for you with both the keyboard patch + Benjamin's patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=95466118 This is still building atm, it should be done in a couple of hours. Like last time you can find install instructions here: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Please give the new test kernel a try and let us know if it fixes the pointing stick. Regards, Hans
Dear Hans, Dear Benjamin, The new kernel is perfect, the patch gives the right solution to the sensepoint problem, everything works now properly. Thank you so much for all your great help. Best regards, Edgar
(In reply to Edgar Bertoti from comment #7) > The new kernel is perfect, the patch gives the right solution to the > sensepoint problem, everything works now properly. That is good to hear. I expect Benjamin will submit the sensepoint patch upstream soon then. Benjamin, question what would be the downside of just using the multi-input approach for all win-8 mt-touchpads ? I guess this would cause a non-function mouse to show up on all of them for the mouse-device which is used when in mouse emulation mode. But AFAICT having such a non-functional mouse would not be a big deal and the current solution of adding more and more MT_CLS_WIN_8_FORCE_MULTI_INPUT quirks (there are quite a few already) feels a bit like a game of whack-a-mole?
(In reply to Hans de Goede from comment #8) > I expect Benjamin will submit the sensepoint patch upstream soon then. I'll try to send it today, yes. We might be able to take it through an rc of this cycle, we'll see. > > Benjamin, question what would be the downside of just using the multi-input > approach for all win-8 mt-touchpads ? > > I guess this would cause a non-function mouse to show up on all of them for > the mouse-device which is used when in mouse emulation mode. But AFAICT > having such a non-functional mouse would not be a big deal and the current > solution of adding more and more MT_CLS_WIN_8_FORCE_MULTI_INPUT quirks > (there are quite a few already) feels a bit like a game of whack-a-mole? Well, it's not an easy answer. IIRC it would work in 90% of the cases, with just one extra mouse. But the problem is that we are reverting back to where we were few years ago when there were devices that would export one kind of device on one report ID, and will configure it through different report IDs. Basically we had: Report ID 1 -> mouse Report ID 2 -> touchpad Report ID 3 -> pen Feature Report ID 4 -> touchpad configuration Feature Report ID 5 -> pen configuration Feature Report ID 6 -> another touchpad configuration And so on, so forth. We need a way to group the collections together, and using the application usage was a way. So I agree we should be able to do something, but this should be carefully engineered, because we have corner cases that are hard to solve :(
sent as https://lore.kernel.org/linux-input/20221219105521.73467-1-benjamin.tissoires@redhat.com/T/#u
(In reply to Benjamin Tissoires from comment #9) > Well, it's not an easy answer. IIRC it would work in 90% of the cases, with > just one extra mouse. But the problem is that we are reverting back to where > we were few years ago when there were devices that would export one kind of > device on one report ID, and will configure it through different report IDs. > > Basically we had: > Report ID 1 -> mouse > Report ID 2 -> touchpad > Report ID 3 -> pen > Feature Report ID 4 -> touchpad configuration > Feature Report ID 5 -> pen configuration > Feature Report ID 6 -> another touchpad configuration > > And so on, so forth. We need a way to group the collections together, and > using the application usage was a way. > > So I agree we should be able to do something, but this should be carefully > engineered, because we have corner cases that are hard to solve :( Thanks the detailed answer. Should it not be reasonably easy to detect this in mt_probe() by looking at the descriptors and then dynamically enable (or disable) the MT_QUIRK_FORCE_MULTI_INPUT behavior ?
Or maybe detect there are actually 2 mouse devices in the descriptors and then automatically enable MT_QUIRK_FORCE_MULTI_INPUT ?
> Or maybe detect there are actually 2 mouse devices in the descriptors and then automatically enable MT_QUIRK_FORCE_MULTI_INPUT ? Not a bad idea but would require to pre-parse the report descriptor before hid_connect(HID_INPUT_CONNECT). Another option would be to say that Mice collections are likely to be separated, and would force another hidinput if we get another input one. Or even better, only regroup the input reports by applications when we are in the HID_FEATURE_REPORT, not HID_INPUT_REPORT phase. i.e, if there are multiple input reports with the same application -> create multiple hidinput, but if we are having a feature report, attach it to the first found hidinput matching the application. And on that note, I should probably add some tests for that trackstick support on hid-tools...
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on None. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.