| Summary: | Property setting become ineffective after chvt | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Yuxuan Shui <yshuiv7> | ||||||
| Component: | Input/libinput | Assignee: | Peter Hutterer <peter.hutterer> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | peter.hutterer | ||||||
| Version: | 7.7 (2012.06) | ||||||||
| Hardware: | Other | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Yuxuan Shui
2017-05-02 01:08:39 UTC
What version of libinput and xf86-input-libinput? I can't seem to reproduce this here with git master of both. libinput 1.7.1 xf86-input-libinput 0.25.0 sorry, tried again, I can't reproduce this here. Are you sure now desktop environment is interfering here? are the device ids the same before and after? Please attach your xorg.log as well I'm not running as desktop environment. I'm using awesomeWM only. device ids are the same before and after. I can see the device itself being disabled then enabled. but I can't reproduce this problem by disabling then enabling the device. Created attachment 131226 [details]
Xorg log
sorry, can't see anything in the log and this doesn't make sense, we call LibinputApplyConfig() during DEVICE_ON and should thus apply the right configuration. I think the only way to debug this is if you start building the xf86-input-libinput driver from source and put a few ErrorF() in there (the xserver's equivalent of printf) to figure out what's going on. (In reply to Peter Hutterer from comment #6) > sorry, can't see anything in the log and this doesn't make sense, we call > LibinputApplyConfig() during DEVICE_ON and should thus apply the right > configuration. I think the only way to debug this is if you start building > the xf86-input-libinput driver from source and put a few ErrorF() in there > (the xserver's equivalent of printf) to figure out what's going on. I can do that. Can you give me a pointer which file and which lines to look at? there's only one file :) search for DEVICE_ON and start from there, on VT switch you're getting a DEVICE_OFF followed by DEVICE_ON from the server. Those are the only two entry points you have to care about here. I think I understand what is happening. The particular mouse I'm using, shows up as two device in "xinput list", one as a keyboard, one as a pointer. Somehow the keyboard has the exact same properties as the pointer. So I only enable natural scrolling on the pointer, and it works. But when I switch back from vt, xf86libinput would try to apply config twice, once for each "device". And because natural scrolling is not enabled on the "keyboard", and the keyboard's config is restore after the pointer, natural scrolling becomes disabled for the pointer. If I enable natural scrolling on both device, things work out fine. I think the confusing part is how one physical device can have two sets of different properties. And change either set will change the behavior of the device, but the change only shows up in one set of properties. Please attach an evemu-describe of your device so I can reproduce this here, thanks. Created attachment 131441 [details]
evemu-describe
https://patchwork.freedesktop.org/patch/158004/ CC-d you on it, please give it a test, thanks. ping? commit 87f9fe3a6fafe60134c69419c0e551b9dbc112b7 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Wed May 24 08:42:02 2017 +1000 Only initialize properties that match capabilities on a subdevice |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.