Main window cannot be interacted with a pen input

[denilsonsa]

I have a Wacom tablet. If I try to use it to interact with the main window, absolutely nothing happens. I'm forced to either use a mouse or press ↹ Tab for keyboard navigation.

However, the settings dialog works perfectly fine with the stylus pen. I've tried a couple other tools using PyQt5 (qtqr and ckb-next), and both also work fine. So, there is something special about the vdu_controls main window. Something might be filtering the events or something.

I have not tested with touch input, because none of my displays support it. (Well, I can try testing touch input on Steam Deck, but I'm not sure if I have all the dependencies to run vdu_controls on that system; so don't count on it.)

If you have some additional debugging code that you want me try, just tell me. :)

---

In summary:

Input method	Main window	Settings window
Keyboard	✓	✓
Mouse	✓	✓
Stylus pen	✗ ☹	✓
Touch-screen	untested	untested

[denilsonsa]

I just noticed the KDE Discover tool also can't be interacted with a stylus pen (and I know it works on touch screen).

[digitaltrails]

The main window is a QWidget, the Settings dialog is a QDialog, maybe that has something to do with it.

I'll take a closer look at the code. Maybe there's some attempt at keyboard shortcuts or similar getting in the way. Someone asked for keyboard shortcuts, but I could not get Qt and KDE to cooperate, but there may be some code hanging around from the attempt.

I'll also do some googling, maybe it's a known thing.

That will all be tomorrow, clocking off shortly.

[digitaltrails]

The Preset dialog is also a QDialog, maybe that will work - it would be interesting if it did.

[denilsonsa]

Yes, the preset dialog works fine.

For what's worth, I'm using KDE/Plasma on Xorg.

[digitaltrails]

Yes, the preset dialog works fine.

For what's worth, I'm using KDE/Plasma on Xorg.

Thanks, me too, KDE Plasma on Xorg. Generally I don't see basic functional differences from gnome/qt/xfce/deepin, mainly it's a completely missing feature or sizing/layout annoyances.

Might be worth preserving your config files by moving them out of the way. Then start with no config files and see if the problem goes away.

Signing off for the night.

[denilsonsa]

Might be worth preserving your config files by moving them out of the way. Then start with no config files and see if the problem goes away.

That's what I did in #37. Unless you mean all the KDE/Qt configuration. That would be too drastic.

Anyway, take care! I appreciate the work you've put in this tool, and all the work you're doing debugging these kind of issues from random people from the web. ;)

[digitaltrails]

That's what I did in #37. Unless you mean all the KDE/Qt configuration. That would be too drastic.

No, you did exactly right. I only mean start with no vdu_controls config files - just in case they were part of the issue.

Playing about with the KDE configs is way too dangerous. All my CPU/RAM/... monitoring desktop widgets mysteriously disappeared sometime in the last few days, the only way I could figure how to get them back was to go to google, then get the right files from backup.

Anyway, take care! I appreciate the work you've put in this tool, and all the work you're doing debugging these kind of issues from random people from the web. ;)

I prefer coding to doing crosswords. I've been with Linux since 0.10, so it's good to contribute something, even if it's small.

I do appreciate the feedback.

[digitaltrails]

I'm going to check in some code based on what I read in bugreport.qt.io bug QTBUG-65559. Based on the documentation at https://doc.qt.io/qt-6/qwidget.html#tabletTracking-prop, I'm not sure it's related in a useful way to this issue. But this is the only lead I've found so far.

It's a stab in the dark and may do nothing useful, in which case I'll reverse it. I should probably have put this on a branch, but it's not like this is a super active project and the changes are pretty trivial.

[digitaltrails]

It may also be possible for me to create a virtual tablet using EVDEV via python-Linux-evdev. Perhaps using a joystick as a standi-n. I would need a evdev definition for a tablet. The script snoop-evdev.py in https://github.com/digitaltrails/opentrack-opal could be used to get that info:

python snoop-evdev.py -c /dev/input/event24

Where the correct EVDEV event device number can be identified by looking at ls -l /dev/input/by-id

Which would result in something like:

device /dev/input/event22, name "SteelSeries SteelSeries Rival 110 Gaming Mouse", phys "usb-0000:02:00.0-10/input1"
Begin capabilities
('EV_SYN', 0)
    ('SYN_REPORT', 0)
    ('SYN_CONFIG', 1)
    ('SYN_MT_REPORT', 2)
    ('SYN_DROPPED', 3)
    ('?', 4)
('EV_KEY', 1)
    (['BTN_LEFT', 'BTN_MOUSE'], 272)
    ('BTN_RIGHT', 273)
    ('BTN_MIDDLE', 274)
    ('BTN_SIDE', 275)
    ('BTN_EXTRA', 276)
    ('BTN_FORWARD', 277)
('EV_REL', 2)
    ('REL_X', 0)
    ('REL_Y', 1)
    ('REL_WHEEL', 8)
    ('REL_WHEEL_HI_RES', 11)
('EV_ABS', 3)
    (('ABS_MISC', 40), AbsInfo(value=0, min=0, max=255, fuzz=0, flat=0, resolution=0))
('EV_MSC', 4)
    ('MSC_SCAN', 4)
End capabilities

I'm not sure how much work this would be, so I can't guarantee I'll follow through on it.

[denilsonsa]

I'm sorry to report that 3ceb8a772fc86a1f1a4f9fdfed0e6d212515d15e did not change the behavior. I still cannot interact with the main window using a tablet.

I've never created a virtual device like that. That sounds interesting. But I understand that it can potentially be a lot of work. (I'm not saying you should spend money on this, and I'm already very grateful for you investigating this issue; but I've seen an old wacom tablet for as low as €1 on the second-hand market.)

$ ls -l /dev/input/by-id/usb-WACOM*
lrwxrwxrwx 1 root root 10 Jan 16 13:35 /dev/input/by-id/usb-WACOM_CTE-640-U_V4.0-3-event-mouse -> ../event14
lrwxrwxrwx 1 root root  9 Jan 16 13:35 /dev/input/by-id/usb-WACOM_CTE-640-U_V4.0-3-mouse -> ../mouse1

$ ./snoop-evdev.py -c /dev/input/by-id/usb-WACOM_CTE-640-U_V4.0-3-event-mouse
BTN_MIDDLE
device /dev/input/by-id/usb-WACOM_CTE-640-U_V4.0-3-event-mouse, name "Wacom Graphire4 6x8 Pad", phys "usb-0000:00:14.0-4.2/input0"
Begin capabilities
('EV_SYN', 0)
    ('SYN_REPORT', 0)
    ('SYN_CONFIG', 1)
    ('SYN_MT_REPORT', 2)
    ('SYN_DROPPED', 3)
('EV_KEY', 1)
    ('BTN_FORWARD', 277)
    ('BTN_BACK', 278)
    ('BTN_STYLUS', 331)
('EV_REL', 2)
    ('REL_WHEEL', 8)
('EV_ABS', 3)
    (('ABS_X', 0), AbsInfo(value=0, min=0, max=1, fuzz=0, flat=0, resolution=0))
    (('ABS_Y', 1), AbsInfo(value=0, min=0, max=1, fuzz=0, flat=0, resolution=0))
    (('ABS_MISC', 40), AbsInfo(value=0, min=0, max=0, fuzz=0, flat=0, resolution=0))
End capabilities
Exiting: -c = capabilities only

$ ./snoop-evdev.py -c /dev/input/by-id/usb-WACOM_CTE-640-U_V4.0-3-mouse 
[…]
OSError: [Errno 25] Inappropriate ioctl for device

I now remember that VirtualBox will use a virtual absolute pointing device (like a tablet) to control the guest OS mouse pointer. Not sure if that would be enough to reproduce the issue. I think there are at least two websites with VM images ready to download: https://www.osboxes.org/ and https://www.linuxvmimages.com/ In any case, you can try https://patrickhlauke.github.io/touch/tracker/tracker-force-pressure.html in Chrome to see how the device is being detected (here I get a "pointer (mouse)" and a "pointer (pen)"). Firefox has issues with it.

[digitaltrails]

OK I'll back out that change.

You are correct that it would better to obtain some hardware, there are probably too many unknowns to trust that a virtual environment is presenting the right clues.

If the problem could be reduced to a small example perhaps it would be easier to raise a bug against Qt. I might look at that.

[denilsonsa]

(The Wacom Graphire tablet I have is so old that Wacom doesn't provide drivers for newer Windows versions. That's also why some people are selling it cheap. Regardless, it works out-of-the-box flawlessly on any Linux.)

I agree, if you can provide a minimal example application, containing just the dummy shell of vdu_controls main window, without any of the behavior, then it will be easier to try it on different systems (e.g. inside VirtualBox) and even experiment variations until we get to the exact conditions for the bug.

[digitaltrails]

Here is a small script that creates a minimal QMainWindow, and if passed the argument -use-dialog uses a QDialog instead.

import sys
from PyQt5.QtWidgets import QWidget, QDialog, QLabel, QApplication, QMainWindow, QVBoxLayout, QHBoxLayout, QComboBox, QSlider
from PyQt5.QtCore import Qt

def layout(title):
    main_layout = QVBoxLayout()
    combo_box = QComboBox()
    combo_box.addItem("Option 1")
    combo_box.addItem("Option 2")
    main_layout.addWidget(QLabel(title))
    main_layout.addWidget(combo_box)
    main_layout.addWidget(QSlider(Qt.Horizontal))
    return main_layout

app = QApplication(sys.argv)

if "-use_dialog" in sys.argv:
    print("Using QDialog")
    window = QDialog()
    window.setLayout(layout("QDialog"))
else:
    print("Using QMainWindow")
    window = QMainWindow()
    widget = QWidget()
    widget.setLayout(layout("QMainWidget"))
    window.setCentralWidget(widget)

window.show()
sys.exit(app.exec_())

[denilsonsa]

I've tested this tiny script, and I can interact with both QDialog and with QMainWindow.

[digitaltrails]

I've tested this tiny script, and I can interact with both QDialog and with QMainWindow.

Interesting. It might take a while, but I guess I need to look at adding features/settings from vdu_controls to the QMainWindow example until it breaks.

[denilsonsa]

I've tested launching the bootable Manjaro Linux installer ISO into VirtualBox, which provides a "VirtualBox USB Tablet". I couldn't reproduce the bug over there. :-\

Then I tried forwarding the USB device of my wacom tablet from the host to the guest, and I could reproduce the issue. This means with a plain vanilla unchanged KDE user profile (i.e. the one from the bootable installer environment) the issue can be reproduced, which means it's certainly not some configuration on mine.

BTW, no mouse-over effect and no mouse-click happens when this bug exists.

[denilsonsa]

Found the issue! https://github.com/denilsonsa/vdu_controls/commits/wacom-testing

Unconditionally accepting and/or returning True for all events on the MainWindow is causing the bug. Now it's your turn to figure out why you did that, and if you should just remove it.

[digitaltrails]

Found the issue! https://github.com/denilsonsa/vdu_controls/commits/wacom-testing

Unconditionally accepting and/or returning True for all events on the MainWindow is causing the bug. Now it's your turn to figure out why you did that, and if you should just remove it.

Thanks for tracking that down. The code seems unnecessary. It may have been cut and paste from something else I've written. Or it may be hanging around from various attempts at trapping desktop style changes and reacting to them. I will take a closer look at the revision history and at other stuff I've written.

[denilsonsa]

Great! The latest commit almost fixes it.

I can interact with all VDU controls, but I cannot interact with anything in the bottom bar. Neither the refresh button nor the hamburger menu button respond to pen events. (I'm not even mentioning the progress bar, as that one can't be interacted with anyway.) (Huh… By saying I'm not mentioning it, I just mentioned it…)

BTW, the refresh button can't be focused by keyboard. It probably should.

[digitaltrails]

Great! The latest commit almost fixes it.

I can interact with all VDU controls, but I cannot interact with anything in the bottom bar. Neither the refresh button nor the hamburger menu button respond to pen events. (I'm not even mentioning the progress bar, as that one can't be interacted with anyway.) (Huh… By saying I'm not mentioning it, I just mentioned it…)

BTW, the refresh button can't be focused by keyboard. It probably should.

I missed the eventFilter in the BottomToolBar because it has a different name. Hopefully it should not work.

[digitaltrails]

BTW, the refresh button can't be focused by keyboard. It probably should.

Funny that the hamburger menu can be focused. I wonder what that's about - I'll take a look.

[denilsonsa]

Great! Pen input now works fine!

Question: what's that little "d2" thing right next to the hamburger menu? I don't know what "d2" means. But I know it's a button(-ish) and it can be clicked and that opens the menu, for some reason.

[digitaltrails]

Great! Pen input now works fine!

Question: what's that little "d2" thing right next to the hamburger menu? I don't know what "d2" means. But I know it's a button(-ish) and it can be clicked and that opens the menu, for some reason.

That is preset icon. Do you have a preset with a d and a 2 in its name? If you do, clicking on the preset icon, it just opens the hamburger menu. The main idea was to have some indicator of what preset is active.

I think the reason the refresh-button and the preset-icon cannot be focused is that they are both "Actions", where as the hamburger menu is a button. Buttons are allowed keyboard shortcuts, which, I guess, might make them focusable/tab-able.

Actions don't appear to have shortcuts by default. I've just tried assigning a shortcut, but that didn't seem to work - but I've had trouble with assigning shortcuts. I wonder it it would be easier to make everything buttons, but there may be a reason/restriction behind the difference.

[digitaltrails]

I've changed the refresh QAction to a QToolButton, it can now be focused.

I left the Preset QAction, it's a bit tricky to change. It invokes the Hamburger Menu button, which would mean two buttons down at the same time. That kind of works, but both buttons light up, and only one unlights when released.

It's debatable whether the preset indicator should actually do anything. Perhaps it should bring up a presets-only menu, but that's seems a pointless amount of work considering the presets are already on the hamburger menu. I could perhaps figure out how to have a non-clickable icon in the toolbar. I think I'll park this for further consideration.

Interestingly the refresh spinner starts immediately if the refresh button is pressed, but spinning is delayed if refresh in the hamburger menu is selected. Probably the menu is blocking the GUI thread.

[digitaltrails]

Interestingly the refresh spinner starts immediately if the refresh button is pressed, but spinning is delayed if refresh in the hamburger menu is selected. Probably the menu is blocking the GUI thread.

I found that the refresh from the menu was doing extra unnecessary work. Probably a hangover from past refactoring.

[denilsonsa]

Nice, with the latest commits the refresh action seems to work smoother, without blocking the GUI thread.

Activating a preset still blocks the UI thread, instead of lighting up the progress bar.

You may have some extra refactoring to do, but the main issue from this bug report is fixed!

https://user-images.githubusercontent.com/121676/213637638-f6af5eea-1f0a-45dd-8ef4-52741d6551c2.mp4

vdu_controls is now quicker to start, responds nicely to pen input, responds quicker to… well, everything. This new version is definitely better. :tada: :+1:

My AOC displays seem to work fine with sleep-modifier=0.75, but using 0.5 or lower throws too many errors.

[digitaltrails]

Nice, with the latest commits the refresh action seems to work smoother, without blocking the GUI thread.

Activating a preset still blocks the UI thread, instead of lighting up the progress bar.

The Preset activation doesn't separate data and UI. I hadn't noticed the issue because I tend to use the right-mouse menu available on the system-tray icon, so the main UI is always minimised. Even less so since I implemented activation via solar-elevation. But it could be fixed (maybe not before release 1.9).

You may have some extra refactoring to do, but the main issue from this bug report is fixed!

Peek.2023-01-20.08-07.mp4 vdu_controls is now quicker to start, responds nicely to pen input, responds quicker to… well, everything. This new version is definitely better. tada +1

Cleaning up the data-refresh UI-refresh boundary has paid off nicely.

My AOC displays seem to work fine with sleep-modifier=0.75, but using 0.5 or lower throws too many errors.

Rather than being too optimistic, I should probably change the default back to 1.0, normal speed.

Thanks for all the help. I close this one.