This affects tablets that are not listed in libwacom, specifically, tablets where libwacom does not provide the stylus axis information. On tablet init, we check the event codes. A tablet may have ABS_Z and thus have rotation. Or it has BTN_TOOL_MOUSE + ABS_TILT_X/Y and thus have rotation. On init, all axes are marked as 'changed' to ensure we send the data in the first event. For non-libwacom tablets, the tool has the same bits set as the tablet provides, so if mouse+tilt is there, we have rotation on all tools. But the code itself relies on ABS_Z for rotation on all the styli (except mouse/lense). In the case of Aiptek tablets we do have mouse+tilt but we *don't* have ABS_Z. If the first tool that comes into proximity is *not* the mouse/lens tool [1], we try to update the rotation by accessing ABS_Z. This leads to a null-pointer dereference in tablet_update_artpen_rotation() on the very first event. See https://bugzilla.redhat.com/show_bug.cgi?id=1535755. It doesn't matter that the tool never sends the actual events - because all axes are marked as 'changed' on proximity in, we always access the axis on the first event and crash. [1] see also Bug 104911
https://lists.freedesktop.org/archives/wayland-devel/2018-February/036827.html
And for extra fun, the series starting here: https://lists.freedesktop.org/archives/wayland-devel/2018-February/036853.html
commit cbb4ec1e3e76b64ec53c25036976e0374aaf41de Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Mon Feb 5 09:11:42 2018 +1000 tablet: don't set rotation on a tool if we don't have ABS_Z
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.