Activity for Jason Gerecke
-
Jason Gerecke modified ticket #55
One CTL-472 not working in Gentoo after installing wacom packages
-
Closing as a duplicate of https://github.com/linuxwacom/input-wacom/issues/75
-
Thanks Thomas. The sysinfo script didn't detect a pen sensor either; it shows a touchscreen from ELAN rather than Wacom but no pen. Are you sure your device supports the PN556W stylus? Searching for info on the XPS 15 9550 it sounds like it only has a traditional capacitive touchscreen. If that's the case, you'll only be able to make use of purely-capacitive pens. An "active pen" like the PN556W requires special support from the touchscreen controller to work.
-
Hi Thomas. Could you please first make sure that you are running an X11 session? You can check your current session type by running echo $XDG_SESSION_TYPE inside a terminal. If it prints out "wayland", then you'll need to switch the session type. If you use the GNOME desktop, you should be able to do this by logging out, clicking the "gear" icon next to the login button, slecting "GNOME on Xorg", and then logging back in. Afterwards, run the echo command again to double-check that you've indeed started...
-
2.6.32: Limit input-wacom to only provide "new" devices to RHEL 6.10
-
2.6.32: MobileStudio Pro 13/16 and Cintiq Pro 13FHD/16UHD support 10 fingers
-
Recgonize Scientific Linux as a variant of RHEL
-
Add support for kernel module signing and enforcement
-
input-wacom 0.42.0
-
No Stylus on CentOS 7.5
-
input-wacom 0.41.0
-
backport: HID: wacom: Replace touch_max fixup code with static touch_max definitions
-
HID: wacom: convert Wacom custom usages to standard HID usages
-
backport: HID: wacom: Correct touch maximum XY of 2nd-gen Intuos
-
backport: HID: wacom: convert Wacom custom usages to standard HID usages
-
backport: HID: wacom: Move handling of HID quirks into a dedicated function
-
Merge branch 'jiri/for-4.18'
-
HID: wacom: Replace touch_max fixup code with static touch_max definitions
-
HID: wacom: Move handling of HID quirks into a dedicated function
-
HID: wacom: Correct touch maximum XY of 2nd-gen Intuos
-
Merge branch 'jiri/for-4.19'
-
backport: HID: wacom: Correct logical maximum Y for 2nd-gen Intuos Pro large
-
HID: wacom: Correct logical maximum Y for 2nd-gen Intuos Pro large
-
travis: Hotfix Coverity's Travis integration patch
-
Hi, would you be willing to open a new issue for this at https://github.com/linuxwacom/xf86-input-wacom/issues/? I can reproduce that the delay still exists (this issue was closed when the unexpected "jump" that also occurred was fixed), and it doesn't look like an option to control the amount of time it takes for scrolling to "kick in" was ever added.
-
Intuos 2 pen doesn't work
-
It has been an awfully long time since that fix was made, so it isn't too surprising that the codesn't match up exactly. I'll close this bug for now since it seems to be working, but if you have problems in the future feel free to let us know. We should be able to turn that fix into something that you can apply.
-
The Intuos2 hardware seems to be flaky and often causes issues for our driver. Please see bugs [#309], [#247], [#207], and [#173]. Bug [#247] in particular has a workaround that might fix the issue for you. EDIT: Fixed links
-
Intuos 2 pen doesn't work
-
The Intuos2 hardware seems to be flaky and often causes issues for our driver. Please see bugs #309, #247, and #207, and #173. Bug #247 in particular has a workaround that might fix the issue for you.
-
Input filtering on Intuos S
-
Issue should be resolved in the 4.18 kernel that should be released in mid- to late August. The fix has been backported to the input-wacom tree as well and should be available in its next release (0.41.0). See https://github.com/linuxwacom/xf86-input-wacom/issues/14
-
HID: wacom: Support "in range" for Intuos/Bamboo tablets where possible
-
backport: HID: wacom: Support "in range" for Intuos/Bamboo tablets where possible
-
Merge branch 'jiri/for-4.17'
-
HID: wacom: Release device resource data obtained by devres_alloc()
-
backport: HID: wacom: Release device resource data obtained by devres_alloc()
-
Use `dracut` if available to update RHEL/Fedora initramfs
-
Include generated config.h header in all kernels
-
2.6.32: Fix abs get/set accessors for 2.6.36/2.6.37
-
2.6.32: Check WACOM_QUIRK_BBTOUCH_LOWRES before modifying Bamboo coords
-
2.6.32: make sure only one touch point is reported
-
ExpressKey Remote support - 2 - evtest working
-
Wacom HID 4822 and Wacom HID 4824 touchscreens behave like mouse (no pitch to zoom, no gestures, so scrolling, etc.) and report non-existing battery
-
Based on the data you gathered earlier showing the hardware to be sending bad data, I'm going to close this as (partially) fixed in xf86-input-wacom 0.36.1. If your hardware really is at fault, updating to 0.36.1 isn't going to be any better, but there's nothing we can do about it since it looks like a real touch... On the off-chance that it was just a fluke, you could try capturing data again and sending me a new log. I'll look through and see if it (still) looks like a hardware issue, or if there...
-
touchscreen stopped dragging with finger
-
Closing as fixed by 414ee8130dd8b04512f38b7d9d29ecce3e30a86e in xf86-input-wacom 0.36.1
-
Looks like we posted at the same time :D The "xsetwacom" command-line utility can be used to configure pen settings in some environments, including the buttons. Give man xsetwacom a read, as well as https://github.com/linuxwacom/xf86-input-wacom/wiki/xsetwacom. Most GNOME3-like desktops (GNOME/Unity/Cinnamon) have a dedicated control panel for the tablet that does /most/ things, but its presence can unfortunately prevent xsetwacom from working properly if you need special configuration. Those control...
-
Looks like we posted at the same time :D The "xsetwacom" command-line utility can be used to configure pen settings in some environments, including the buttons. Give man xsetwacom a read, as well as https://github.com/linuxwacom/xf86-input-wacom/wiki/xsetwacom. Most GNOME3-like desktops (GNOME/Unity/Cinnamon) have a dedicated control panel for the tablet that can interfere with xsetwacom, but it should /mostly/ work. Those control panels depend on the "libwacom" library to detect tablets (unlike...
-
Looks like we posted at the same time :D The "xsetwacom" command-line utility can be used to configure pen settings in some environments, including the buttons. Give man xsetwacom a read, as well as https://github.com/linuxwacom/xf86-input-wacom/wiki/xsetwacom. Most GNOME3-like distributions (GNOME/Unity/Cinnamon) have a dedicated control panel for the tablet that can interfere with xsetwacom, but it should /mostly/ work. Those control panels depend on the "libwacom" library to detect tablets (unlike...
-
Wacom one not working on linux mint even after driver installation
-
Glad to hear its working now :) I'm not entirely sure what happened, but my best guess is that your earlier attempt to install "xf86-input-wacom" from source was the trigger since the "input-wacom" driver doesn't mess with Xorg at all. The fact that "wacom_drv.so" was missing makes me think that maybe you ran make uninstall at some point, which would have removed both anything you installed from source as well as the stock distribution-provided files (since they're both installed with the same names...
-
wacom 0.36.1
-
Indeed the "failed to load module" error is the culprit here. The logs are referring to the Xorg driver module rather than the kernel module we just got sorted out. Normally I would expect the Xorg driver to already be in place, but your earlier attempt to install xf86-input-wacom from source may have broken something (e.g. if you ran make uninstall). You can run ls /usr/lib*/xorg/modules/input/ to see the installed Xorg input drivers -- "wacom_drv.so" should be listed if its installed... You can...
-
Support for Graphire4 6x8 (CTE-640)
-
Good to hear :) I'll go ahead and mark this bug as closed then and remember this if somebody has a similar issue in the future.
-
2.6.30: Fix maximum distance for Bamboo tablets
-
2.6.30: Correct resolution of ISDv4 0x5000 tablet
-
2.6.30: Correct number of buttons for DTU-1141
-
3.17: add to_hid_device macro
-
2.6.30: Backport MTSCREEN ISDv4 devices
-
2.6.30: Backport resolution data (but not implementation)
-
2.6.30: Clean up wacom_features structures
-
2.6.30: Backport TABLETPCE ISDv4 devices
-
2.6.30: Backport missing TABLETPC ISDv4 devices
-
2.6.30: Add missing oVid/oPid data to pen side of split devices
-
4.5: define wacom_is_using_usb_driver as hid_is_using_ll_driver()
-
3.7, 3.17: backport 2cf83833fc9c HID: use kobj_to_dev()
-
3.17: use wacom_hid_report_len unconditionally
-
2.6.30: Backport touch_max data
-
3.17: have only one common check for the powersupply API version
-
automatically detect which powersupply version we are using
-
3.17: fix wacom_destroy_battery
-
Awesome, so that means that the kernel drivers should be sorted out. If the cursor still isn't moving at this point, its an issue with the userspace driver. Could you please provide the output of xinput list now, as well as the contents of your Xorg log? The Xorg log can be hiding in a couple of different spots. You might find it within the /var/log directory or inside the ~/.local/share/xorg directory. If there are multiple Xorg log files, upload the one with the most recent timestamp (it should...
-
Fail the Coverity build if their script cannot be downloaded
-
The output for the "Pad" device in your log above will only provide information about button presses, if the pad has any built into it (I don't think the One has any?) If you run evemu-record on the "Pen" device instead, do you see anything printed out when dragging the pen on the tablet?
-
Check both valid and working state when finding new channels
-
Fail the Coverity build if their script cannot be downloaded
-
Fix -EINVAL error preventing probe of One by Wacom on pre-3.17 kernels
-
Fix tilt-y being overridden with tilt-x
-
Oh, that is looking more promising. Do you see the tablet listed when running sudo evemu-record now?
-
While adding the debug statements, I came across an error that would actually explain the symptoms you experience. Please run the following two commands from within your input-wacom directory to get the update. I think it just might do the trick. $ git checkout -b fix-support-54 $ git pull https://github.com/jigpu/input-wacom.git fix-support-54 Afterwards, compile/install/test the driver like normal. The version number reported by the kernel should be "v1.53-0.38.0.12.ge6e4865"
-
Interesting. The "-22" is "-EINVAL", which our driver's probe function can return in any of several places when an error occurs. We'll have to add some additional debug messages to figure out exactly what is going wrong...
-
Sorry about the delay in replying -- SourceForge has been extremely flaky these past few days. It looks like you're compiling the correct version and that its being installed/loaded correctly. I've double-checked the code and the 056a:037a tablet listed in your lsusb output is exactly what we'd expect. The configuration files also don't seem to have any issues. Basically everything looks good from what I can see. The problem is either with the kernel driver not connecting to the tablet for some reason,...
-
It looks like GNOME already has an issue open for this at https://bugzilla.gnome.org/show_bug.cgi?id=770464 . I would suggest posting a reply to that bug mentioning that the CTH-480 is also affected. This would ensure that you're updated when GNOME begins fixing things. I'll also reply to that bug with some additional technical information to document the issue and provide some information about what steps GNOME might take to fix it.
-
If you already have a Wacom configuration file under the /usr/share/X11/xorg.conf.d/ directory (e.g. 70-wacom.conf or 50-wacom.conf) you shouldn't need to place a file in /etc/X11/xorg.conf.d). If you don't have such a file, the example configuration can be found at https://sourceforge.net/p/linuxwacom/xf86-input-wacom/ci/master/tree/conf/70-wacom.conf Looks like we need to fix the link on that page :)
-
You'll need to install a development version of the "input-wacom" (kernel) driver, not the "xf86-input-wacom" (Xorg) driver in order to get your tablet working. To do this, install the "git" utility and run git clone https://github.com/linuxwacom/input-wacom.git to clone the latest version of our repository, which has support for your tablet. Instructions for compiling and installing the code can be found at https://github.com/linuxwacom/input-wacom/wiki/Installing-input-wacom-from-source.
-
Those logs seem to indicate that the hardware is occasionally sending an apparently-phantom 2nd touch. The touch doesn't move at all: it just appears at some location, and then some time later disappears. The two phantom touches recorded each lasted for a short-but-meaningful amount of time: 1 second and 0.5 seconds. I wouldn't expect reloading the kernel module to help, but maybe other phantom touches last longer and the reload resets the hardware... Not sure. I think the second issue could also...
-
Thanks for those captures. They look very similar, with about the only notable difference being Synatptics' use of the "Abs MT" axis labels in XI2 rather than the vanilla "Abs" labels we use. I didn't have any luck replaying the Synaptics log directly (no lines drawn in Sketchboard; I haven't yet tried NextCloud) so it'll be hard for me to know if any particular change is going to fix things. Do you know if you're using the libinput driver or the Synaptics driver on the 7150? You can check the Xorg.0.log...
-
data: Remove FIXME from Huion H610 Pro
-
Applying that patch to version 0.34.0 should give the same results as testing against 0.36.0. There don't seem to be any changes that would affect this, though its hard to be certain since that version is over a year old. I wonder why Ubuntu hasn't pulled an updated version. At the very least they should be using 0.35.0 since the expanded pressure range used by 0.34.0 has been reported to cause problems for two applications and only 0.35.0 has a way to revert back to the regular pressure range if...
-
BTW, I think this might be the same issue as https://sourceforge.net/p/linuxwacom/bugs/349/ so I've posted the instructions there as well...
-
Lenovo pen upper side button state not tracked out of prox
-
I may have found the source of this bug. Please follow the steps below to compile and install a fixed version of the driver (you can find a list of necessary build dependencies at http://linuxwacom.sourceforge.net/wiki/index.php/Xf86-input-wacom). Let me know if you're still able to reproduce this issue afterwards. $ git clone https://github.com/jigpu/xf86-input-wacom.git -b fix-touch-freeze $ cd xf86-input-wacom $ ./autogen.sh --prefix=/usr --libdir=$(for F in /usr/lib*/xorg/modules/input/../../../;...
-
Okay, I think I've managed to find the culprit. Replaying the captured event sequence with the fix results in things staying in sync, at least. Please follow the steps below to compile and install a fixed version of the driver (you can find a list of necessary build dependencies at http://linuxwacom.sourceforge.net/wiki/index.php/Xf86-input-wacom). Let me know if you're still able to reproduce this issue afterwards. $ git clone https://github.com/jigpu/xf86-input-wacom.git -b fix-touch-freeze $ cd...
-
Something like tablet / driver programming is going to require hands-on time to learn. Documentation is spotty so you'll probably have to have to work with existing developers to find your way around the code, practices, etc. I got involved with this project years and years ago when I was annoyed by the lack of pressure sensitivity in a Java program I was using at the time. I worked with the developers here to understand the application side of things and add in support. Later on I returned to work...
-
Excellent! These logs seem to capture the point where things de-synchronize. The XI2 events show things working normally right up until contact ID 7287. According to the kernel, what happens is two contacts (7287 and 7288) appear simultaneously; the next report has two more contacts appear (7289 and 7290). The third report is where things diverge: the kernel says contact 7287 disappears, contact 7288 moves, and a fifth contact (7291) appears. XI2 doesn't report contact 7287 disappearing, however....
-
CTL-471 CursorProximity doesn't work
-
Okay, good to know. I'll have to find somebody with an eraser to test this before sending it to the mailinglist, but at least you can benefit from it in the meantime :)
-
Could you possibly capture some logs from a non-Wacom touchscreen for review? We don't have any to compare against, which makes it difficult to do anything more than guess about what might be wrong. It would be ideal if you could open up sketch.io, run the script at https://gist.githubusercontent.com/jigpu/b7b47e4bede584cec8562f666fd84af4/raw/5ae43a4a1a9b770822479cbabdf1ffd24e3685bb/capture.sh and then draw a set of three lines with a single finger. Hit CTRL+C afterwards. Please use a mouse or ALT+TAB...
1 >