Hello, Up to 2.9.2 all worked (xorg-server-1.17.4). However, when used in virtualbox guest Xorg.0.log is floated with the following messages, these messages slows down the response time significantly: --- (WW) dropping event due to full queue! --- So I thought to give the 2.10.0 a try, but it does not produce any event when I examine xev output, although I do see button 2 pressed and I do see move up/down is sane. Same configuration is working with 2.9.2 apart of the above. Configuration: --- Section "InputClass" Identifier "MyMouse" MatchProduct "VirtualBox USB Tablet" MatchIsPointer "on" Option "EmulateWheel" Option "EmulateWheelButton" "2" EndSection --- xev output while scrolling: none. Will be happy to provide any other information.
please run evemu-record on the virtualbox device, it's a lot easier to debug this if I know the event stream. thanks.
Created attachment 120909 [details] mouse.info
Created attachment 120910 [details] mouse.log
Nice utility! I see that middle button is reported correctly: --- E: 0.289708 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +19ms E: 1.258794 0004 0004 589827 # EV_MSC / MSC_SCAN 589827 E: 1.258794 0001 0112 0001 # EV_KEY / BTN_MIDDLE 1 E: 1.258794 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +969ms E: 1.714737 0004 0004 589827 # EV_MSC / MSC_SCAN 589827 E: 1.714737 0001 0112 0000 # EV_KEY / BTN_MIDDLE 0 --- I also see that abs y is reported correctly: --- E: 158.211711 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +48ms E: 158.308174 0003 0001 12679 # EV_ABS / ABS_Y 12679 E: 158.308174 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +97ms E: 158.337671 0003 0001 12715 # EV_ABS / ABS_Y 12715 E: 158.337671 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +29ms E: 158.404366 0003 0001 12752 # EV_ABS / ABS_Y 12752 --- But no wheel.
(In reply to Alon Bar-Lev from comment #0) > (WW) dropping event due to full queue! this one has been around since at least 2.6.0, I didn't go past this on my testing. Surprised this wasn't noticed/filed before. bisected to commit 3dcf6f123c54fd3104bcb79677cd347972abea4c, looks like in EvdevWheelEmuFilterMotion() we rely on old_vals to be set and 3dcf6 removed updating those vals.
Hi! So I guess it is my fault. It has been over a year, I am a little bit lost. So, from looking at old mails, It seemed I prepared a series of a dozen patches to address a number of problems that were affecting a stylus I own. First problem was bug 82181: when the stylus is moved horizontally, it does not report a ABS_Y valuator. Xorg send an event to update the positions giving the new X pos and also the old Y pos, but with only one valuator. Unfortunately, some libraries (Qt) look at the raw valuator values to compute a HiRes position, and fails when only one valuator was present. One goal of the patch series was to always send the two X/Y valuator positions. Second problem was bug 82250: it seems that some libraries (gdk, this time) expect to have position valuator when a button press is sent, and some other stuff (I forgot the details). There was a third bug, mentionned in passing in a mail from Peter on the mailing-list: > So the mask reset needs to be a bit smarter but from a quick skim of the > code it looks like that's a general problem anyway. if the REL_WHEEL is sent > in the same EV_SYN frame as the ABS_X event, both rel_queued and abs_queued > are set and the mask is submitted twice to the server (once as rel, once as > abs mask) and we get duplicate events. So congratulations I guess: you found > a bug and won the chance to fix that too ;) sorry about that. So, the series of twelve patches was supposed to fix everything by simplifying the code and making sure that only complete events were sent to Xord (complete events with all the absolute valuators set: when the kernel was sending an update for only part of the valuators, the evdev driver would add the other values.) This series of patchs solved all the bugs I had filled, and I libed very happily with my stylus and a patched evdev on my system. Now, one year later. I see that Peter only applied the 5 first patches of my series. I don't remember what happens, I think I remembered there was a problem with the other patches, which I took 3 months to fix and when I sent them again Peter never replied, probably too busy on something more important. Also, I no longer use the stylus that started all this, so I didn't notice that my patches were no longer in. But, apparently, I introduce a new bug that took one year to be discovered. I am not sure what is the best way forward. Should we push the entire series of patch and then fix the new issue? Should we fix the new issue without pushing the remaining of the patches? Should we revert the 5 first patches? Not many people were hit by the bugs I tried to fix (I was not alone, I saw someone else complain on the internet on what seemed to be exactly the same bug.) The problem of course is that, one year later, I have forgotten everything about evdev...
Eric, sorry about the CC without more info, i was hurrying out the door just as I finished bisecting. (In reply to Éric Brunet from comment #6) > I see that Peter only applied the 5 first patches of my series. I don't > remember what happens, I think I remembered there was a problem with the > other patches, which I took 3 months to fix and when I sent them again Peter > never replied, probably too busy on something more important. after a bit of digging, I think I found your patches, email from Oct 03 2015, message-id 4491247.kEnszVmx0K@tardis.lps.ens.fr. does that sound right? They're numbered 0007 to 0014. If so, I'm very sorry about missing those, I can't remember them and my best explanation is that they came in just before XDC after which I had a holiday which must've swamped them out of my inbox. > But, apparently, I introduce a new bug that took one year to be discovered. that's a fairly common problem but there isn't much we can do about that, we simply don't have the test suites to catch these thing easily. this case is a niche case too, wheel emulation on an absolute device. you can see why I'm hesitant to push things to libinput instead of major reworks in evdev. > I am not sure what is the best way forward. Should we push the entire series > of patch and then fix the new issue? Should we fix the new issue without > pushing the remaining of the patches? Should we revert the 5 first patches? > Not many people were hit by the bugs I tried to fix (I was not alone, I saw > someone else complain on the internet on what seemed to be exactly the same > bug.) The problem of course is that, one year later, I have forgotten > everything about evdev... tbh, at this point I'd rather keep any major rework out of evdev and focus on libinput as a long-term replacement. libinput is still waiting for tablet support though at least we're really close to merging it. I've got simple fixes pending for this issue, so I'd like to merge them instead of reworking something.
http://patchwork.freedesktop.org/patch/70447/ That's the cause for the (WW) dropping event due to full queue! warning, if you are using wheel emulation on a virtualbox device, you must set this value.
Created attachment 121013 [details] [review] 0001-Restore-wheel-emulation-for-absolute-devices.patch the simplest patch I could come up with to restore the wheel emulation. Shouldn't have any side effects, but please test it. Thanks
Hi Peter! > Eric, sorry about the CC without more info, i was hurrying out the door just > as I finished bisecting. Now problem, I know you're busy, I figured it out. > after a bit of digging, I think I found your patches, email from Oct 03 > 2015, message-id 4491247.kEnszVmx0K@tardis.lps.ens.fr. does that sound > right? They're numbered 0007 to 0014. If so, I'm very sorry about missing > those, I can't remember them and my best explanation is that they came in > just before XDC after which I had a holiday which must've swamped them out > of my inbox. Hmm, no: I sent patches 6 to 15 on Mar 29 2015. Interesting time warp. October is close enough that I am positively certain I didn't send you a mail at the time. > tbh, at this point I'd rather keep any major rework out of evdev and focus > on libinput as a long-term replacement. Ok. > libinput is still waiting for tablet > support though at least we're really close to merging it. I've got simple > fixes pending for this issue, so I'd like to merge them instead of reworking > something. Yeah. Just a side remark, but you are probably aware of it. When I upgraded from fedora 21 to fedora 23, I missed an essential functionality: middle button emulation was assigned to three finger tapping on my clickpad, while I wanted it on two finger tapping, and I couldn't configure it the way I wanted from the kde control panel. You guessed what happened: it was just a switch from evdev to libinput. This was a sufficiently good reason for me to force evdev back on my clickpad. You want, and need, to simplify the forest of options of evdev to make code more maintanable in libinput. Your users will want configurability. I don't know how you will solve this problem...
(In reply to Peter Hutterer from comment #9) > Created attachment 121013 [details] [review] [review] > 0001-Restore-wheel-emulation-for-absolute-devices.patch > > the simplest patch I could come up with to restore the wheel emulation. > Shouldn't have any side effects, but please test it. Thanks Working, thanks! But still I see the following and there is significant slow down: (WW) dropping event due to full queue! (WW) dropping event due to full queue! (WW) dropping event due to full queue!
(In reply to Alon Bar-Lev from comment #11) > (In reply to Peter Hutterer from comment #9) > > Created attachment 121013 [details] [review] [review] [review] > > 0001-Restore-wheel-emulation-for-absolute-devices.patch > > > > the simplest patch I could come up with to restore the wheel emulation. > > Shouldn't have any side effects, but please test it. Thanks > > Working, thanks! > > But still I see the following and there is significant slow down: > (WW) dropping event due to full queue! > (WW) dropping event due to full queue! > (WW) dropping event due to full queue! ok... now I understand comment#8... so I tried small values and reached 2000 to avoid seeing this error. $ xinput set-int-prop "VirtualBox USB Tablet" 261 16 2000 But response time of wheel is not that great... takes ages to start scrolling, then it is completing the gap by scrolling very fast. What else can I tune?
I think you're hitting another condition: there's code that resets the horizontal axis for any vertial wheel emulation scroll to avoid building up horizontal movements (see EvdevWheelEmuFilterMotion(), the if (pAxis) towards the end). In your case because of the high resolution you're guaranteed to get x and y axis movements (no way can you move that perfectly vertically), so the axes likely end up resetting each other until at some point you accumulated just enough to trigger the scroll event, that's when it finally sends events (and 2000 is probably too small, which is why you see so many events). try removing that condition, meanwhile I'll think about how to make this work for higher thresholds.
Created attachment 121056 [details] [review] 0001-Don-t-reset-the-other-axis-on-wheel-emulation-scroll.patch goes on top of the first patch and should fix your erroneous scroll motion
(In reply to Peter Hutterer from comment #14) > Created attachment 121056 [details] [review] [review] > 0001-Don-t-reset-the-other-axis-on-wheel-emulation-scroll.patch > > goes on top of the first patch and should fix your erroneous scroll motion Thanks! much better! Although still inconsistent when the actual scroll begins since I start moving up/down. I tried values of 5000 and 10000 and it seems to have no effect. 50000 performs very slow scroll, but at least I have control over up/down.
Hi! I do not know if it is side effect or not... now when I scroll up and then down without releasing middle button, it seems to continue scrolling up until it virtually reach the starting point only then it scrolls down. I believe that when direction changes it should effect immediately. Thanks!
Created attachment 121098 [details] [review] 0001-Restore-wheel-emulation-for-absolute-devices.patch updated patch. the oldVals didn't update when filtering kicked in, so the delta wasn't the real delta but that from the start position - which explains the behaviour your saw.
Hi! Patches from Comment#17 (attachment#121098 [details] [review]) + Comment#14 (attachment#121056 [details] [review]) - wheel emulation does not work at all, same as before xev shows no events at all. Thanks!
I'll need you to put some ErrorF() into the code to debug this then. It works fine here with a device that is effectively identical to yours and it works when I replay your event recording. So this is likely something local to your setup, or some weird quirk that isn't visible in the recording. Please make sure you have the inertia set to the correct value too. ErrorF() works identical to printf, you'll see the messages in the xorg log file. Put a couple of markers into EvdevWheelEmuFilterMotion(), see if you can find out why the events aren't triggered. For reference, the two patches go on top of 6a3beab (evdev 2.10.1)
(In reply to Peter Hutterer from comment #19) > Please make sure you have the inertia set to the correct value too. this was the issue. I left it as 50000 and it caused the behaviour. now I set it to 500 and it is quite responsive and I have no "(WW) dropping event due to full queue!" messages. this is great! one issue though... when emulating wheel, so far the cursor remain in its position while scroll up/down was issued. now the cursor is moving as well. so when cursor reaches the top/bottom scrolling stops.
this doesn't happen here and not with your recording either. Do you have the device added twice? Note that depending on the driver/virtual box behaviour, your device may not be grabbed when you move it, so you're still moving the host cursor and once you move out of the window, it'll stop sending events. The patches don't affect cursor movement, if the event was filtered before it still is filtered now.
http://patchwork.freedesktop.org/patch/71082/ http://patchwork.freedesktop.org/patch/71083/
Hi! Checked this again after restarting X and cursor does not move now... maybe it happened due to use of dynamic xinput, not sure. Sorry about that. However, I have another challenge... When I scroll up cursor stays where it is, scrolling is good now in term of responsibility for inertia=50. However, two issues... now I am sure X is restarted... so no left overs. 1. The scroll amount is possible to the exact amount of the distance between the cursor and the edge of the screen. This means that if I put the cursor at middle of Y, then scroll down, the amount I can scroll is Max(Y)-Y. 2. When I release the middle button the cursor appears at the Max(Y), it makes sense as the mouse is absolute device and it reports the position at that location... (???)
both of these are an artifact of using an absolute pointer, yes. there isn't anything I can do about this. 1. is caused by your device not sending any further events once you reach the edge of the screen 2. is probably caused by the motion event after the release. but either way, it means the pointer jumps to the correct position - without that, the device wouldn't be an absolute input device.
Thank you so much for the support! I guess wheel emulation using absolute device is not something that is very usable. Just a thought... maybe it can be implemented as constant scroll at speed of Y-base(Y). So that if Y-base(Y) / N == movement at speed N*step. This way there is no need to handle screen edge, and jumps will be minimized.
interesting idea, could be worth a try. not sure I want to add that to evdev though, it's in maintenance mode. but using this for wheel emulation under libinput would be worth it.
commit d24431a1863c49aa9edcabf535ffa64bfa87053c Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Thu Jan 14 10:41:46 2016 +1000 Restore wheel emulation for absolute devices commit 7b0a65d989117d1b071101221ff1b97c1b4d1946 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri Jan 15 14:01:02 2016 +1000 Don't reset the other axis on wheel emulation scroll buildup
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.