Bug 196678 - x11-servers/xorg-server: Update to 1.20.4 + make config/devd recognize /dev/input/eventX from multimedia/webcamd
Summary: x11-servers/xorg-server: Update to 1.20.4 + make config/devd recognize /dev/i...
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-x11 mailing list
URL:
Keywords: feature, patch
Depends on: 196978
Blocks:
  Show dependency treegraph
 
Reported: 2015-01-13 11:09 UTC by Hans Petter Selasky
Modified: 2019-03-24 00:23 UTC (History)
32 users (show)

See Also:


Attachments
Updated devd backend patch (13.35 KB, patch)
2015-01-13 11:09 UTC, Hans Petter Selasky
no flags Details | Diff
updates to devd backend in diff form. (15.39 KB, patch)
2015-01-13 11:38 UTC, Alex Kozlov
no flags Details | Diff
Devd patch for Xorg server (15.58 KB, patch)
2015-09-04 06:36 UTC, Hans Petter Selasky
no flags Details | Diff
Devd file for Xorg server (13.41 KB, text/x-c)
2015-09-04 06:37 UTC, Hans Petter Selasky
no flags Details
Devd patch for Xorg server (15.73 KB, patch)
2015-09-14 08:56 UTC, Hans Petter Selasky
no flags Details | Diff
Devd file for Xorg server (13.47 KB, patch)
2015-09-14 08:57 UTC, Hans Petter Selasky
no flags Details | Diff
makes devd to hanle all known input devices (19.55 KB, patch)
2016-02-07 23:45 UTC, rozhuk.im
no flags Details | Diff
Xorg.0.log entries of wacom device (17.49 KB, text/plain)
2016-02-24 06:51 UTC, Shane
no flags Details
makes devd to hanle all known input devices and unknown in /dev/input/ (21.53 KB, patch)
2016-02-26 01:26 UTC, rozhuk.im
rozhuk.im: maintainer-approval+
Details | Diff
makes devd to hanle all known input devices and unknown in /dev/input/ (21.84 KB, patch)
2016-03-01 08:02 UTC, rozhuk.im
no flags Details | Diff
patch-config_devd.c with device type autodetection (21.74 KB, patch)
2016-07-11 13:05 UTC, Vladimir Kondratyev
no flags Details | Diff
devd: support webcamd, evdev, uhid, all from /dev/input (44.52 KB, patch)
2016-10-11 11:36 UTC, rozhuk.im
no flags Details | Diff
devd: support webcamd, evdev, uhid, all from /dev/input (44.30 KB, patch)
2017-02-12 01:17 UTC, rozhuk.im
no flags Details | Diff
update Xorg to 1.19.2 and integrate collective devd enhancements (85.02 KB, patch)
2017-03-10 16:35 UTC, Matthew Rezny
no flags Details | Diff
wacom plug/unplug log with different drivers (16.92 KB, text/plain)
2017-03-11 02:59 UTC, rozhuk.im
no flags Details
update Xorg to 1.19.3 and integrate collective devd enhancements (86.77 KB, patch)
2017-03-16 16:40 UTC, Matthew Rezny
no flags Details | Diff
update Xorg to 1.19.6 and integrate collective devd enhancements (137.68 KB, patch)
2018-03-18 11:57 UTC, Vladimir Kondratyev
no flags Details | Diff
update Xorg to 1.19.6 and integrate collective devd enhancements (145.32 KB, patch)
2018-08-05 19:26 UTC, Vladimir Kondratyev
no flags Details | Diff
update Xorg to 1.19.6 and integrate collective devd enhancements (146.07 KB, patch)
2018-08-09 22:12 UTC, Vladimir Kondratyev
no flags Details | Diff
update Xorg to 1.20.1 and integrate collective devd enhancements (147.13 KB, patch)
2018-09-23 22:57 UTC, Vladimir Kondratyev
no flags Details | Diff
update Xorg to 1.20.3 and integrate collective devd enhancements (147.13 KB, patch)
2018-10-27 23:49 UTC, Vladimir Kondratyev
no flags Details | Diff
update Xorg to 1.20.4 and integrate collective devd enhancements (146.30 KB, patch)
2019-03-23 23:30 UTC, Vladimir Kondratyev
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Petter Selasky freebsd_committer 2015-01-13 11:09:17 UTC
Created attachment 151548 [details]
Updated devd backend patch

Hi,

In order to support applications like Webcamd, Xorg needs to listen for character device events and not device driver events. Please find attached an updated devd.c patch for the xorg-server. This patch also make /dev/input/eventX work flawlessly with Xorg again, like tablets and touchpads.

--HPS
Comment 1 Koop Mast freebsd_committer 2015-01-13 11:32:14 UTC
Hi, can you redo the patch as a diff against the current xorg-server port, so we can see the diff you made? Thanks.
Comment 2 Alex Kozlov freebsd_committer 2015-01-13 11:38:35 UTC
Created attachment 151549 [details]
updates to devd backend in diff form.
Comment 3 Vitaly Magerya 2015-02-08 16:17:50 UTC
In that patch input/event* devices are assigned to the "evdev" driver, but there's no such driver on FreeBSD... Is there maybe a plan to port xf86-input-evdev?

Also, would it be possible to make get_usb_id work on USB devices that are not provided through webcamd (e.g. ums, ukbd and uhid)?
Comment 4 Hans Petter Selasky freebsd_committer 2015-02-08 16:46:19 UTC
Hi,

See:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196978

--HPS
Comment 5 Hans Petter Selasky freebsd_committer 2015-02-08 16:46:59 UTC
Yes, we can make the WEBCAMD IOCTL standard and work for those devices aswell if requested.

--HPS
Comment 6 Vitaly Magerya 2015-02-08 17:51:28 UTC
> See:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196978

Oh, that's pretty great actually.

> Yes, we can make the WEBCAMD IOCTL standard and work for those
> devices aswell if requested.

If that's the easiest way to get those ids, then yes, it is very
much requested, along with IOCTLs to get vendor and device name
strings. Without that our current DEVD backend (and this patch)
is only half-finished.
Comment 7 Hans Petter Selasky freebsd_committer 2015-02-10 17:14:10 UTC
File a PR for this and assign it to me.

--HPS
Comment 8 Hans Petter Selasky freebsd_committer 2015-02-10 17:14:35 UTC
BTW: Is there any news about getting this PR submitted to ports?

--HPS
Comment 9 Hans Petter Selasky freebsd_committer 2015-09-04 06:36:28 UTC
Created attachment 160696 [details]
Devd patch for Xorg server
Comment 10 Hans Petter Selasky freebsd_committer 2015-09-04 06:37:35 UTC
Created attachment 160697 [details]
Devd file for Xorg server
Comment 11 Jan Beich freebsd_committer 2015-09-14 07:56:41 UTC
With the patch applied config/devd no longer honors xorg.conf e.g.,

  Section "InputClass"
          Identifier       "keyboard defaults"
          MatchIsKeyboard  "true"
          Option           "XkbLayout" "us(dvorak)"
          Option           "XkbOptions" "terminate:ctrl_alt_bksp"
  EndSection

  Section "InputClass"
          Identifier       "mouse defaults"
          MatchIsPointer   "true"
          Option           "InvX" "true"
          Option           "InvY" "true"
          Option           "Emulate3Buttons" "false"
  EndSection

but the following still works:

  Section "InputClass"
          Identifier       "dummy defaults"
          Option           "Ignore" "true"
  EndSection

which suggests Match* have regressed.
Comment 12 Hans Petter Selasky freebsd_committer 2015-09-14 08:56:22 UTC
Created attachment 161034 [details]
Devd patch for Xorg server
Comment 13 Hans Petter Selasky freebsd_committer 2015-09-14 08:57:09 UTC
Created attachment 161035 [details]
Devd file for Xorg server
Comment 14 Hans Petter Selasky freebsd_committer 2015-09-14 08:58:09 UTC
Hi Jan,

Can you re-test using the updated, attached patches?

--HPS
Comment 15 Hans Petter Selasky freebsd_committer 2015-09-14 08:58:51 UTC
(In reply to Jan Beich from comment #11)

Looks like there was a missing OR of the device attributes into "attrs".
Comment 16 Jan Beich freebsd_committer 2015-09-14 12:38:38 UTC
Thanks. keyboard/mouse work fine now.

evdev is a bit confusing due to ATTR_TOUCHPAD hardcoding even for joysticks, touchscreens or tablets without "touch" function.
Comment 17 Hans Petter Selasky freebsd_committer 2015-09-14 12:50:04 UTC
Do you have a better suggestion?
Comment 18 Hans Petter Selasky freebsd_committer 2015-09-14 12:52:22 UTC
Maybe we could do an IOCTL to figure out more specific information ...
Comment 19 Hans Petter Selasky freebsd_committer 2015-09-14 12:58:48 UTC
Is this something which can be solved as a separate bug item?
Comment 20 Vitaly Magerya 2015-09-14 13:25:43 UTC
Evdev devices should already have an IOCTL that exposes that
information; see 'libevdev_has_event_type' and 'libevdev_set_fd'
over at [1].

For example, if 'libevdev_has_event_type(device, EV_ABS)' is
true, then it's a touchpad. (Maybe an additional test for
'libevdev_has_event_code(evdev, EV_KEY, BTN_TOUCH)' being true
is also needed, I'm not sure).

I think this can be corrected later -- if this patch will be
accepted at all, improving it will be easy enough from there.

[1] http://cgit.freedesktop.org/libevdev/tree/libevdev/libevdev.c
Comment 21 Jan Beich freebsd_committer 2015-09-14 13:32:57 UTC
(In reply to Hans Petter Selasky from comment #18)
> Maybe we could do an IOCTL to figure out more specific information ...

Maybe also fetch device description similar to mousedrv(4x)

  $ xinput
  [...]
  ⎜   ↳ USB Laser Mouse                           id=8    [slave  pointer  (2)]
  ⎜   ↳ input/event0                              id=9    [slave  pointer  (2)]
  ⎜   ↳ input/event1                              id=10   [slave  pointer  (2)]
  ⎜   ↳ input/event2                              id=11   [slave  pointer  (2)]

(In reply to Hans Petter Selasky from comment #19)
> Is this something which can be solved as a separate bug item?

evdev(4x) (lack of) configuration is already big improvement over wacom(4x). Users with more than one tablet and/or touchscreen are probably rare. And joysticks still lack actual (e.g. xpad) or generic (from hid-core.c) driver to be usable.

comment 16 confusion was from the following experiment

  Section "InputClass"
          Identifier "wacom only touch/pad"
          MatchIsTablet "true"
          Option "Ignore" "true"
  EndSection

vs.

  Section "InputClass"
          Identifier "wacom only stylus/eraser"
          MatchIsTouchpad "true"
          Option "Ignore" "true"
  EndSection
Comment 22 rozhuk.im 2016-02-07 23:45:07 UTC
Created attachment 166727 [details]
makes devd to hanle all known input devices

This patch tested with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206086

* proper handle input devices: native and webcamd 
* use ioctl() calls to get more info/detect device type for: keyboard, mouse, joystick and event.
* wacom/event, keyboard and joystick devices get proper device name via device specific ioctls
* set usb_id/pnp_id for all devices: sysctl() + webcam specific ioctls. 
* use sysctl() for non webcamd devices
* wacom works with xf86-input-evdev and xf86-input-wacom drivers, select via config "InputClass" section
* many other small improvements
Comment 23 Arto Pekkanen 2016-02-18 20:46:43 UTC
(In reply to rozhuk.im from comment #22)

I am no developer, but I am hoping this patch or similar like it get accepted asap ... Currently one cannot use USB gamepads with the XInput protocol because devd backend won't assign a driver for them. The XInput protocol is important, because there are still very good emulators that only work on FreeBSD with XInput, since their other alternative is the Linux specific API.
Comment 24 Hans Petter Selasky freebsd_committer 2016-02-22 17:01:56 UTC
Rozhuk: Do you know if anyone is activly working on bringing these patches in?
Comment 25 Hans Petter Selasky freebsd_committer 2016-02-22 17:50:36 UTC
Rozhuk:

devd.c:605:1: warning: no previous prototype for function 'as_cfg_load_dir' [-Wmissing-prototypes]
as_cfg_load_dir(char *dir_name)
^

Maybe missing some header file include?

--HPS
Comment 26 Shane 2016-02-24 06:49:42 UTC
I have a bamboo touch and just tried this. The bamboo had stopped working a while ago and I had left it disabled and not got around to looking at it.

After adding this patch to xorg-server and rebuilding with DEVD enabled I can't get the bamboo to work. Using HAL I can get the stylus/eraser to work but not the touch. I haven't tried to do anything with the buttons. I have installed libevdev libmtdev and xf86-input-evdev.

An older boot dmesg with the bamboo attached can be found at http://shaneware.biz/freebsddebugdata/boot.dmesg

I am now running 10-STABLE built 19/2/2016

%  usbconfig -u 2 -a 6 dump_device_desc
ugen2.6: <CTH-470 Wacom Co.,Ltd.> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (498mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0020 
  idVendor = 0x056a 
  idProduct = 0x00de 
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  <Wacom Co.,Ltd.>
  iProduct = 0x0002  <CTH-470>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001 


%  xsetwacom list devices
usbhid pad                   id: 6   type: PAD       
usbhid stylus                id: 7   type: STYLUS    
usbhid eraser                id: 10  type: ERASER    

% webcamd -l
Available device(s):
webcamd [-d ugen0.1] -N EHCI-root-HUB-Intel -S unknown -M 0
webcamd [-d ugen1.1] -N XHCI-root-HUB-0x1b21 -S unknown -M 0
webcamd [-d ugen2.1] -N EHCI-root-HUB-Intel -S unknown -M 1
webcamd [-d ugen0.2] -N product-0x0024-vendor-0x8087 -S unknown -M 0
webcamd [-d ugen2.2] -N product-0x0024-vendor-0x8087 -S unknown -M 1
webcamd [-d ugen2.3] -N USB-2-0-Hub-vendor-0x1a40 -S unknown -M 0
webcamd [-d ugen2.5] -N USB-Keyboard-vendor-0x05af -S unknown -M 0
webcamd [-d ugen2.6] -N CTH-470-Wacom-Co--Ltd -S unknown -M 0
webcamd [-d ugen2.4] -N USB-Optical-Mouse-Logitech -S unknown -M 0

% ls -la /dev/input/*
crw-rw----  1 webcamd  webcamd  0xd3 23 Feb 17:01 /dev/input/event0
crw-rw----  1 webcamd  webcamd  0xd9 23 Feb 17:01 /dev/input/event1
crw-rw----  1 webcamd  webcamd  0xda 23 Feb 17:01 /dev/input/event2
crw-rw----  1 webcamd  webcamd  0xdb 23 Feb 17:01 /dev/input/js0

by cat'ing each device I can say -
event0 is the stylus/eraser
event1 is the touch
event2 is the 4 buttons on the side
js0 also outputs (less than event2) when the buttons are pressed.

I will add some relevant log entries as an attachment, including the log entries when using HAL.
Comment 27 Shane 2016-02-24 06:51:22 UTC
Created attachment 167354 [details]
Xorg.0.log entries of wacom device
Comment 28 Hans Petter Selasky freebsd_committer 2016-02-24 07:21:36 UTC
Which of the devd patches did you use? You should use the latest one from rozhuk.im@gmail.com in the attachments section.

--HPS
Comment 29 rozhuk.im 2016-02-24 15:09:39 UTC
(In reply to FreeBSD from comment #26)
You must specify input driver by hands:
take file https://sourceforge.net/p/linuxwacom/xf86-input-wacom/ci/master/tree/conf/50-wacom.conf
and replace Driver "wacom" to Driver "evdev"

Or use xf86-input-wacom - it install 50-wacom.conf to /usr/local/share/X11/xorg.conf.d
Comment 30 rozhuk.im 2016-02-24 15:11:55 UTC
(In reply to Hans Petter Selasky from comment #25)
It is not peace of code from other my program, a forgot remove it.

Later i will update patch to handle all existing devices from /dev/input
Comment 31 Shane 2016-02-25 16:26:38 UTC
(In reply to Hans Petter Selasky from comment #28)
I am using the most recent config/devd.c patch dated 2016-02-07

(In reply to rozhuk.im from comment #29)
xf86-input-wacom actually installs wacom.conf.sample into /usr/local/etc/X11/xorg.conf.d which uses InputDevice sections that I didn't get working.

--

I made some progress today, I am now using DEVD with the wacom driver to get some of the bamboo working. The trick seemed to be setting Driver and Type with MatchXXX settings good enough that only one section matches a device.

I now have the following in xorg.conf.d/wacom.conf -

Section "InputClass"
    # wacom pen as a stylus
    Identifier "wacom stylus"
    MatchUSBID "056a:*"
    MatchProduct "Pen"
    Driver "wacom"
    Option "type" "stylus"
    Option "Mode" "Relative"
    Option "Threshold" "20"
EndSection

Section "InputClass"
    # the touchpad function
    Identifier "wacom touch"
    MatchUSBID "056a:*"
    MatchProduct "Finger"
    Driver "wacom"
    Option "type" "touch"
    Option "Mode" "Relative"
    Option "Ignore" "true"
EndSection

Section "InputClass"
    # the buttons on the side
    Identifier "wacom pad"
    MatchUSBID "056a:*"
    MatchProduct "Pad"
    Driver "wacom"
    Option "Ignore" "true"
EndSection

The stylus works, the touchpad works mostly. I can set the pen type to stylus or eraser but I can only get one working at a time.

For now I am setting ignore for touch and pad so I just have a working stylus.

Issues:-

stylus and eraser don't enable simultaneously. man wacom leads to dependent devices needing to be configured using MatchDriver "wacom" and Option "Device" "path", I have not got this to work.

touchpad is intermittent, I particularly see multitouch events occasionally hang the touchpad for some time.

When enabled, pressing the buttons causes input devices to break. This includes the mouse as well as wacom functions. I see the pad appear as a pointer device but thought it was meant to be a keyboard so that various actions can be assigned to each as a keyboard shortcut. The pad is also responsible for creating /dev/input/js0 (as well as event2) which xorg identifies as a joystick.
Comment 32 rozhuk.im 2016-02-25 22:15:19 UTC
(In reply to FreeBSD from comment #31)

I think /usr/local/etc/X11/xorg.conf.d/wacom.conf.sample
is crap.
xf86-input-wacom install working config into: /usr/local/share/X11/xorg.conf.d/50-wacom.conf
If you install my devd patch and xf86-input-wacom then xorg will try to use wacom for your wacom device.
Also xf86-input-wacom install rc.d script that point to devd to not use mouse driver for wacom device.
https://svnweb.freebsd.org/ports/head/x11-drivers/xf86-input-wacom/files/wacom.in?revision=396550&view=markup
So you need to add to /etc/rc.conf[.local] file:
wacom_enable="YES"
and then reboot.

Im no sure that xorg reads your xorg.conf.d/wacom.conf, please check man pages about xorg config files names.


xf86-input-wacom driver does not install any xorg config files to handle wacom devices and does not install rc.d script to prevent use ums driver with wacom.
Comment 33 rozhuk.im 2016-02-26 01:23:44 UTC
0. "xf86-input-wacom driver does not install any xorg config files..." -> 
"xf86-input-evdev driver does not install any xorg config files.."


1. If you install xf86-input-wacom and xf86-input-evdev and want to use xf86-input-evdev then you need:
cp /usr/local/share/X11/xorg.conf.d/50-wacom.conf /etc/X11/xorg.conf.d/55-wacom-evdev.conf

in /etc/X11/xorg.conf.d/55-wacom-evdev.conf replace Driver "wacom" to Driver "evdev"

2. add to /etc/rc.conf[.local] file:
wacom_enable="YES"

3. reboot and replug device after xorg start.

In my system wacom rc.d script starts after devd, so ums driver attach to wacom.
Fix: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207506
Touch does not work with evdev driver on my system.

With xf86-input-wacom Touch is work.
Comment 34 rozhuk.im 2016-02-26 01:26:44 UTC
Created attachment 167426 [details]
makes devd to hanle all known input devices and unknown in /dev/input/

Last and i hope final version of devd patch.
+ handle all devices in /dev/input/
Comment 35 Pierre Guinoiseau 2016-02-26 02:06:17 UTC
With that last patch, does that mean it should work with USB mice too? If yes I will test it, as I need evdev to make my mouse work correctly.
Comment 36 rozhuk.im 2016-02-26 03:58:57 UTC
(In reply to Pierre Guinoiseau from comment #35)
If you mean /dev/input/mice* - yes, try.
Comment 37 Pierre Guinoiseau 2016-02-29 03:13:06 UTC
The patch alone doesn't work: missing header linux/input.h. I think a build dependency is missing, but I don't know which one.

    CC       devd.lo
  devd.c:42:10: fatal error: 'linux/input.h' file not found
  #include <linux/input.h>
           ^
  1 error generated.
  Makefile:665: recipe for target 'devd.lo' failed
Comment 38 Hans Petter Selasky freebsd_committer 2016-02-29 08:10:47 UTC
You need to install webcamd first or the v4l_compat port.
Comment 39 Arto Pekkanen 2016-02-29 10:39:16 UTC
(In reply to Hans Petter Selasky from comment #38)

A patch on devd backend should not require installation of external components such as v4l_compat or webcamd. The patch should instead include the relevant bits from the required headers.
Comment 40 rozhuk.im 2016-02-29 15:04:00 UTC
(In reply to Arto Pekkanen from comment #39)
I will fix it and update patch in next 5-6 hours.
Comment 41 rozhuk.im 2016-03-01 08:02:02 UTC
Created attachment 167594 [details]
makes devd to hanle all known input devices and unknown in /dev/input/

linux/input.h now not required.
Comment 42 Sergey V. Dyatko 2016-03-01 17:28:49 UTC
with patch proposed by rozhuk.im@gmail.com I have following on Xorg.0.log:
[ 88205.351] (II) XINPUT: Adding extended input device "kbdmux0" (type: KEYBOARD, id 6)
[ 88205.359] (II) config/devd: kbdmux is enabled, ignoring device atkbd0
[ 88205.414] (II) config/devd: detected event: SYNAPTICS Synaptics Large Touch Screen, bustype=0003, vendor=06cb, product=1d10, version=0111
[ 88205.424] (II) config/devd: adding input device /dev/input/event0
[ 88205.424] (**) SYNAPTICS Synaptics Large Touch Screen: Applying InputClass "touchpad catchall"
[ 88205.424] (**) SYNAPTICS Synaptics Large Touch Screen: Applying InputClass "Default clickpad buttons"
[ 88205.425] (II) LoadModule: "synaptics"
[ 88205.425] (II) Loading /usr/local/lib/xorg/modules/input/synaptics_drv.so
[ 88205.425] (II) Module synaptics: vendor="X.Org Foundation"
[ 88205.425]    compiled for 1.17.2, module version = 1.8.2
[ 88205.425]    Module class: X.Org XInput Driver
[ 88205.425]    ABI class: X.Org XInput driver, version 21.0
[ 88205.425] (II) Using input driver 'synaptics' for 'SYNAPTICS Synaptics Large Touch Screen'
[ 88205.425] (**) SYNAPTICS Synaptics Large Touch Screen: always reports core events
[ 88205.425] (**) Option "Device" "/dev/input/event0"
[ 88205.425] (EE) synaptics: SYNAPTICS Synaptics Large Touch Screen: Synaptics driver unable to detect protocol
[ 88205.425] (EE) PreInit returned 11 for "SYNAPTICS Synaptics Large Touch Screen"
[ 88205.425] (II) UnloadModule: "synaptics"

any hints?
Comment 43 Jakob Alvermark 2016-03-01 18:48:02 UTC
I have a Lenovo Thinkpad Yoga 12 (Broadwell) with touchscreen and stylus.

The stylus works fine with the wacom driver.
The touchscreen is detected as SYNAPTICS Synaptics Touch Digitizer V04

It does not work with the synaptics driver, but almost with the evdev driver.
To override the synaptics driver I have this in my xorg.conf:
Section "InputClass"
        Identifier "touch"
        Driver "evdev"
        MatchUSBID "06cb:*"
EndSection

I can touch the screen and drag things around, but about half the time there is no ButtonRelease event when I lift my finger off the screen.
Comment 44 Sergey V. Dyatko 2016-03-02 13:55:47 UTC
(In reply to Jakob Alvermark from comment #43)

with 
Section "InputClass"
        Identifier "touch"
        Driver "evdev"
        MatchUSBID "06cb:*"
EndSection
I can touch the screen and drag windows too, and yes, about half the time there is no ButtonRelease event.
lenovo ideapad z400 touch

[tiger@laptop]:~>sudo usbconfig -d ugen0.2 dump_device_desc
ugen0.2: <Synaptics Large Touch Screen SYNAPTICS> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (144mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x06cb 
  idProduct = 0x1d10 
  bcdDevice = 0x0004 
  iManufacturer = 0x0001  <SYNAPTICS>
  iProduct = 0x0002  <Synaptics Large Touch Screen>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001
Comment 45 Jan Beich freebsd_committer 2016-03-09 08:52:29 UTC
(In reply to rozhuk.im from comment #33)
> Touch does not work with evdev driver on my system.

Did you try with MULTITOUCH=off (default)? evdev(4x) seems to misdetect multitouch support unlike wacom(4x), see bug 196978 comment 7 [1]. 2.10.x made MULTITOUCH=on mandatory, so I'm holding off on update to contact upstream but so far ENOTIME.
Comment 46 Vladimir Kondratyev freebsd_committer 2016-07-11 13:05:43 UTC
Created attachment 172378 [details]
patch-config_devd.c with device type autodetection

Hi, Hans!

I have tested your patch with in-kernel evdev implementation and found it basically working.
Currently it does not work properly with default Xorg configuration file out of box so I wrote some missed parts. Namely:
1. Event device type autodetection (libmagic-alike, derived from xf86-input-evdev driver), so default catchall rules started to work for me
2. name/usb_id gathering via EVIOC* ioctls
3. Automatic blacklisting of native device interfaces if corresponding evdev interface exists.
4. Some other minor improvements.

Resulting file is attached.
Comment 47 rozhuk.im 2016-10-11 11:36:17 UTC
Created attachment 175616 [details]
devd: support webcamd, evdev, uhid, all from /dev/input

This patch include all evdev from (Vladimir Kondratyev from comment #46), also add initial support for uhid devices (tested with logitech joystick).
libusbhid (from system) used for uhid support.
Comment 48 rozhuk.im 2017-02-12 01:17:37 UTC
Created attachment 179892 [details]
devd: support webcamd, evdev, uhid, all from /dev/input

Update to build with Xorg 1.18.4
Comment 49 Andriy Gapon freebsd_committer 2017-02-28 09:35:33 UTC
Can someone please commit this?
Comment 50 Vladimir Kondratyev freebsd_committer 2017-02-28 10:47:33 UTC
(In reply to Andriy Gapon from comment #49)
I think character device enumeration and monitoring, and maybe, device type autodetection should be moved to libdevq.
There was GSOC project with similar aims in 2016 that resulted in nothing.
Comment 51 Andriy Gapon freebsd_committer 2017-02-28 13:09:56 UTC
FWIW, the latest patch failed for me in poudriere:
/wrkdirs/usr/ports/x11-servers/xorg-server/work/xorg-server-1.18.4/missing: aclocal-1.15: not found
WARNING: 'aclocal-1.15' is missing on your system.
...
gmake[1]: *** [Makefile:706: aclocal.m4] Error 12

I had to add:
USE_AUTOTOOLS=  aclocal
Comment 52 Matthew Rezny freebsd_committer 2017-03-04 23:40:26 UTC
I had not noticed this PR until very recently. I had separately reworked the devd config backend a few months ago when starting on 1.19, not adding functionality but just adapting for an API change and cleaning up the code (which yielded the memory leak fix in the 1.18.4 update).

I have reviewed the last patch on this PR. While the improved functionality is much desired, the could be improved. I spotted enough issues (e.g. an inner loop re-using the index variable of the outer loop for an unrelated purpose, a series of calls that goto a cleanup label on failure, but only after overwriting the working pointer with NULL, etc) that I decided to make a second, more aggressive, cleanup pass after merging my changes for compat with 1.19.

There will soon be a CFT for X.org 1.19.x including the updated devd config backed and an option to use the udev config backend via libudev-devd. I am currently testing 1.19.2, but the release tarball is missing files so I expect a 1.19.3 release soon.

TL;DR there is progress to get this to ports, new patch Real Soon Now
Comment 53 rozhuk.im 2017-03-09 08:53:15 UTC
(In reply to Vladimir Kondratyev from comment #50)

devd code is a very small part of patch.
Comment 54 rozhuk.im 2017-03-09 09:10:49 UTC
(In reply to Andriy Gapon from comment #51)

On my systems - OK.
Try reinstall autotools.
Comment 55 rozhuk.im 2017-03-09 09:26:37 UTC
(In reply to Matthew Rezny from comment #52)

"inner loop re-using the index variable of the outer loop for an unrelated purpose"
get_dev_type_by_path()
reuse 'i' and it is OK.

"a series of calls that goto a cleanup label on failure, but only after overwriting the working pointer with NULL, etc"
options = input_option_new(options, "device", dev_path);
	if (NULL == options)
		goto err_out;
...
err_out:
...
	input_option_free_list(&options);
This is from Hans Petter Selasky patch, I do not check is input_option_new() work as realloc() (return NULL on fail but do not free mem).

Can you provide more details/feedback?
Comment 56 Matthew Rezny freebsd_committer 2017-03-09 15:21:33 UTC
(In reply to rozhuk.im from comment #55)

I know there are multiple authors of this revision, I did not look through the different versions to attribute changes to anyone, and I certainly do not mean to criticize anyone, rather I criticized the state of the resulting code which was a mix of styles and had some errors that could be due to multiple authors and/or following bad examples elsewhere. So, I passed through it and cleaned it in such a way to try to minimize errors. I certainly must thank everyone who has contributed to the devd config code and I hope everyone has added their name to the list of copyrights.

The double loop with a re-used index variable is in get_dev_type_by_path. The outer loop iterates i with an early continue until the correct device is found in the table. Once it finds the right entry, two assignments are made, one of which, path_offset, depends on the current value of i as its an index into hw_type_path. Then, the inner loop re-uses i to compute the value to assign to dev_name_size. Since we eventually return from within the outer loop, it doesn't matter to the overall flow that the value of i has changed to an unrelated meaning, but there are two more assignments before that return that intend to use i as an index into hw_type_path[]. This variable re-use is only safe if flags and xdriver are assigned before the inner loop, at the same time path_offset was assigned. Perhaps the variable re-use once was safe and it evolved over time such that it no longer is. A safer approach is to use a new variable for the inner loop to keep the meaning clear so that future devd hackers won't get tripped up on the ordering there.

Comparing input_option_new() to realloc() is a good analogy. The list building doesn't realloc, but it does a calloc() every time. If that succeeds, the new list entry is created with the old pointer stored in it. If that fails, it returns NULL. Thus, safely building a list requires use of two pointers, one to hold the list we are building, and one to hold the return value while we check it before assigning to the list pointer. Without the use of a second pointer, the goto circus to call input_option_free_list() was comical. There is of course a much cleaner way to structure the code using two pointers, no gotos, and far fewer lines of code. At least there was an attempt to do the right thing here; the hald and udev config code on the other hand never checks the return value of a call to input_option_new(), so they might call NewInputDeviceRequest() with either NULL, if they lost the whole list, or a partial list, if they lost the initial list after a large calloc failed but then got a new list when a smaller calloc succeeded in a later call to input_option_new(). The upstream code isn't exactly a good example in many ways.
Comment 57 Andriy Gapon freebsd_committer 2017-03-09 16:30:33 UTC
(In reply to rozhuk.im from comment #54)
You probably didn't notice "poudriere" in my comment.
Comment 58 Matthew Rezny freebsd_committer 2017-03-09 17:15:03 UTC
(In reply to Andriy Gapon from comment #57)

Since the patch touches configure.ac, configure tries to regenerate itself but not all of autotools is present in your poudriere environment. The solution is to add USES=autoreconf or not patch configure.ac.

The X.org 1.19.2 release is missing files due to some mistake with autotools and their release script, so I had to put autoreconf in the USES for now. Upstream has stated that there will be a 1.19.3 release to correct the packaging problem, so that is my target for then next update. The patches that go to ports will not require the autoreconf.

I was expecting that release to have happened by now, I did not think it would take more than a day to correct a simple packaging issue. I should probably whip up a 1.19.2 patch with all the devd work for testing while we await the Xorg 1.19.3 release.
Comment 59 rozhuk.im 2017-03-10 00:14:48 UTC
(In reply to Matthew Rezny from comment #56)

Thanks for feedback.

Yes, my mistake, now I see.
get_dev_type_by_path()
...
hw_type_cust->flags = hw_type_path[i].flags;
hw_type_cust->xdriver = hw_type_path[i].xdriver;
should be before
for (i = hw_type_cust->path_offset; i < dev_name_size; i ++) {

input_option_new() - I suspect that here can be some memory leak, but other backends does not handle it and not handle mem alloc fail, so I add only check for allocation to prevent crash.


I hope in new release all devices continue to work and code will read from devd socket more than 1 byte per recv() call :)

I have wacom and logitech joystick to test.


PS: dont forget add Hans Petter Selasky and Vladimir Kondratyev, they do not add self to copyright.
Comment 60 Matthew Rezny freebsd_committer 2017-03-10 16:35:21 UTC
Created attachment 180700 [details]
update Xorg to 1.19.2 and integrate collective devd enhancements

Here is the current Xorg 1.19 work in progress. There's extra patches due to the need to run autoreconf on this release. Test both the devd and udev backends if possible. It may make more sense in the long run to invest our efforts into libudev-devd as that will benefit Wayland as well as X server. For the moment, the devd solution will likely yield the best user experience.
Comment 61 Matthew Rezny freebsd_committer 2017-03-10 17:51:28 UTC
These are the results of my testing for reference. The situation is improved although not yet perfect. 

Input devices are a PS/2 keyboard, a USB2.0 laser-mouse, and a USB1.1 Wacom Graphire3. Kbdmux and sysmouse are in use so the keyboard and mouse situation is easy, those has worked worked with the devd backend since the beginning. The Wacom tablet is the tricky part since up till now it required static config in xorg.conf.d (using half the example file in the port), so it must be present when X starts, but it must NOT be present when the machine boots since ums would take the device before the wacom script in rc.d has a chance to setup the usb_quirks to prevent ums stealing the device. When using a graphical login manager, the result is a window of a few seconds in which the tablet can be plugged in and expected to work correctly; far from ideal. For a while it was possible to avoid the hassle by putting the usb_quirk data in loader.conf, but that no longer works, so it is important to be able to hot-plug the tablet after X is already started.

Using the old devd code patched for 1.19 compat was the the same situation, no handling the wacom table when it is connected.

Using the last patch posted in this PR, modified for 1.19 compat, resulted in the wacom tablet being detected but the evdev driver was loaded, even if I also had a file in xorg.conf.d explicitly specifying the wacom driver. Only if I uninstalled xf86-input-evdev would the wacom driver get loaded. The evdev DDX is not suitable for use with my wacom tablet. When that driver loads, the cursor becomes stuck to the left edge of the screen, button 1 is stuck in the down state, moving the stylus horizontally causes the cursor to move vertically, and I cannot move the cursor elsewhere or click with the mouse since evdev is feeding (incorrect) absolute coordinates from the tablet and a button is already stuck.

After I reworked the devd code and killed at least one obvious bug handling the entries in the device type table, but also passing path as well as device for evdev's benefit, the situation is improved; with both evdev and wacom drivers installed, devd loads the the wacom driver when the tablet is connected and it works as expected. Hooray, getting closer... except there is an issue when unplugging the tablet, a case I had never tired with the old code knowing there'd be no way to reconnect without restarting X. When the tablet is unplugged, the log is flooded with errors from the wacom driver which is freaking out because it can't read from the device.

For comparison I gave the udev config backend a shot. The first run looked good for the tablet, wacom driver loads and tablet works, I can disconnect and reconnect the tablet and it still works without flooding the log, but I have no keyboard or mouse. The log showed that the keyboard and mouse devices were offered to the server but no driver was loaded. After skimming the udev code, I'm not sure how it should work, unless perhaps it only works with devices that supply evdev events, because "driver" is never added of the the options list used to add the device. So, I patched the udev config code to include "driver" with value of "kbd" or "mouse" when the device is one of those types. The result is the udev backend now behaves the same as the devd backend, keyboard and mouse drivers are loaded for kbdmux and sysmouse, and the wacom driver loads for the tablet, but when I disconnect the tablet the log is flooded and upon reconnecting it does not work because the old instance was never unloaded. Hmmm....

In order to troubleshoot I added extra logging in device_removed() so we can see what is happening when the tablet is disconnected. When the tablet is connected, /dev/ugenX.Y and /dev/hid2 appear, neither of which attach drivers (the former is ignored by device_added, the latter has no driver match), hid2 detaches, webcamd starts for the ugenX.Y device and creates a /dev/input/event0, devd sends another event, and finally device_added() loads the wacom driver which attaches to the device. When the tablet is connected, the only thing in the log before the continuous error blast starts is device_removed() ignoring the disconnect of /dev/ugenX.Y; there was no removal event received for /dev/input/event0 and that device node still exists in the filesystem.

My first guess is the device for the hardware is immediately removed but webcamd doesn't remove the synthetic device while it is still opened. However, that doesn't explain the situation with the udev backend. When there was no driver loaded for the keyboard or mouse, it saw the removal of /dev/input/event0 and correctly detached and unloaded the wacom driver, but once I had fixed it to load those keyboard and mouse drivers it no longer saw a removal of the tablet.

Also, there are a number of /dev/hidX entries for various USB device for which no driver is loaded when device_added() processes them. nothing ever loads for /dev/hidX entries regardless of the type. /dev/hid0 is the keypad on a USB handset which should be numeric input and volume up/down, /dev/hid1 is the laser mouse (in parallel with /dev/ums0), and /dev/hid2 is the wacom tablet without webcamd loaded, which now does nothing although once upon a time the wacom DDX did work without webcamd (unsure when that changed). Finally, I tried connecting a USB gamepad I had almost forgotten about since it has never worked in X with the joystick driver, but of course it shows up as a /dev/hidX and no driver attaches. While I have older joysticks that connect to the game port and which have worked (long ago, not tested in years) with the joystick driver and an entry in xorg.conf, those have not been tested with the new devd config code.

Summary: The situation is improved as I can now plug in the tablet any time after boot including after starting X, but still I cannot disconnect the tablet without having to restart X to reconnect it.

HPS: Since webcamd is yours, do you have anything to suggest regarding the missing removal of /dev/input/event0 when disconnecting the wacom tablet while the wacom driver is attached?
Comment 62 Vladimir Kondratyev freebsd_committer 2017-03-11 01:02:07 UTC
(In reply to Matthew Rezny from comment #60)
evdev part of this patch is broken at least on BE64 arches due to long->uint32_t type change in EVIOC* ioctl defines somewhere in transit from my version to your
Comment 63 Vladimir Kondratyev freebsd_committer 2017-03-11 01:29:58 UTC
(In reply to Matthew Rezny from comment #61)
> but when I disconnect the tablet the log is flooded and upon reconnecting it does not work because the old instance was never unloaded. Hmmm....

Support for disconnecting of webcamd evdev devices is tricky due to xorg driver<->webcamd deadlock (Ask Hans for details).
Now it is handled in xf86-input-evdev, see /usr/ports/x11-drivers/xf86-input-evdev/files/patch-src_evdev.c, part started from line 1062
I have similar hack to libinput: https://reviews.freebsd.org/differential/changeset/?ref=236295
Probably, something similar should be done for xf86-input-wacom
Comment 64 rozhuk.im 2017-03-11 02:59:12 UTC
Created attachment 180710 [details]
wacom plug/unplug log with different drivers

(In reply to Matthew Rezny from comment #61)
wacom unplug - look like regression, I fix it before, but no sure is code in upstream.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206086

Patch in ports a bit different:
x11-drivers/xf86-input-wacom/files/patch-src-xf86Wacom.c


Here is log file plug and unplug wacom with my xorg patch, and
xf86-input-wacom-0.34.0_1          =   up-to-date with index
libevdev-1.4.4                     =   up-to-date with index
xf86-input-evdev-2.10.5            =   up-to-date with index
with no private patch.
(I edit xorg config to select evdev/wacom driver and restart xorg)

So your unplug problem may because something changed in code that work with wacom - xf86-input-wacom.
Did your xf86-input-wacom patched?
Comment 65 Vladimir Kondratyev freebsd_committer 2017-03-11 03:56:47 UTC
(In reply to rozhuk.im from comment #64)
> Patch in ports a bit different:
> x11-drivers/xf86-input-wacom/files/patch-src-xf86Wacom.c
>So your unplug problem may because something changed in code that work with wacom - xf86-input-wacom.
> Did your xf86-input-wacom patched?

I do not have wacom devices at all. I have faced with this problem during in-kernel evdev development and code review process half year ago. At first glance, referenced patch should fix it, so sorry for the noise.
Comment 66 Vladimir Kondratyev freebsd_committer 2017-03-11 04:27:38 UTC
(In reply to Vladimir Kondratyev from comment #65)
At second glance this patch may be wrong:
1. Linux returns ENODEV error code for read () if device is gone
2. Webcamd does not know nothing about ENODEV and converts it to default CUSE_ERR_OTHER
3. Cuse converts CUSE_ERR_OTHER to ENXIO and returns it to userworld (wacom driver).
4. Wacom driver ignores ENXIO as EINVAL is expected
Comment 67 Vladimir Kondratyev freebsd_committer 2017-03-11 04:32:40 UTC
(In reply to Vladimir Kondratyev from comment #66)
> 2. Webcamd does not know nothing about ENODEV
2. Webcamd knows nothing about ENODEV
Fixed
Comment 68 Matthew Rezny freebsd_committer 2017-03-11 08:45:52 UTC
(In reply to Vladimir Kondratyev from comment #62)

Thank you for pointing that out. After reviewing the patch you submitted, I have reverted those types to unsigned long. It appears the change to unit32_t was made in Rozhuk's last revision. I have also split that section of code out into a separate get_evdev_flags function similar to how you had it in order to make the device_added function a bit less unwieldy. I had not yet tested the updated devd config code on my ppc64 box but that is one of the things on the 1.19 testing todo list and I might as well try the tablet with the raspi too.
Comment 69 Matthew Rezny freebsd_committer 2017-03-11 11:57:44 UTC
(In reply to Vladimir Kondratyev from comment #66)

Your reply confirms the problem is as I suspected. Thank you for pointing out those patches to evdev and wacom. I had a look at the webcam and wacom code and determined the problem is in the the patch in xf86-input-wacom.

if (priv->isParent && errno == EINVAL) {
    WacomDevicePtr other;
    for (other = common->wcmDevices; other; other = other->next) {
        xf86Msg(X_INFO, "%s: removing automatically added device.\n", other->pInfo->name);
        DeleteInputDeviceRequest(other->pInfo->dev);
    }
} else
/* for all other errors, hope that the hotplugging code will
* remove the device */
    if (errno != EAGAIN && errno != EINTR)
    LogMessageVerbSigSafe(X_ERROR, 0, "%s: Error reading wacom device : %s\n", pInfo->name, strerror(errno));

I should have pasted the exact error message before as it makes it clear webcamd is not the culprit. Since the log message was "Error reading wacom device: Invalid argument", the value of errno must already be EINVAL (it is translated correctly by webcamd), so to be getting the log spam the problem must be that priv->isParent is false. I removed that so it's just "if (errno == EINVAL)" and now the hot plugging works correctly.

[497841.487] (II) Wacom Graphire3 6x8 Pen cursor: removing automatically added device.
[497841.487] (II) UnloadModule: "wacom"
[497841.487] (II) Wacom Graphire3 6x8 Pen eraser: removing automatically added device.
[497841.488] (II) UnloadModule: "wacom"
[497841.488] (II) Wacom Graphire3 6x8 Pen stylus: removing automatically added device.
[497841.489] (II) config/devd: removing input device /dev/input/event0
[497841.489] (II) UnloadModule: "wacom"

Those log messages suggest that is the child devices (stylus, eraser, and cursor) which get culled by this condition, then devd send a removal notice for /dev/input/event0 and the config code commands the device removal. Maybe that was supposed to have been "if (!priv->isParent && errno == EINVAL)".

Jan: As you are the maintainer of the wacom DDX, do you have any input on the wacom situation? What is the correct condition to call DeleteInputDeviceRequest?
Comment 70 rozhuk.im 2017-03-11 12:21:14 UTC
(In reply to Matthew Rezny from comment #69)
Ask Jan Beich, why "priv->isParent" check added.
Comment 71 Jan Beich freebsd_committer 2017-03-11 14:13:57 UTC
(In reply to Matthew Rezny from comment #69)
> What is the correct condition to call DeleteInputDeviceRequest?

According to src/wcmConfig.c Xorg "Server 1.10 will UnInit all devices for us". HAL works fine as is, so isParent check is used to avoid interference.

  (EE) usbhid eraser: Error reading wacom device : Invalid argument
  (EE) usbhid eraser: Error reading wacom device : Invalid argument
  (EE) usbhid eraser: Error reading wacom device : Invalid argument
  (EE) usbhid eraser: Error reading wacom device : Invalid argument
  (EE) usbhid eraser: Error reading wacom device : Invalid argument
  (EE) usbhid eraser: Error reading wacom device : Invalid argument
  (EE) usbhid eraser: Error reading wacom device : Invalid argument
  (EE) usbhid eraser: Error reading wacom device : Invalid argument
  (EE) usbhid eraser: Error reading wacom device : Invalid argument
  (EE) (II) config/hal: removing device usbhid stylus
  usbhid eraser: Error reading wacom device : Invalid argument
  (II) UnloadModule: "wacom"
  (II) config/hal: removing device usbhid eraser
  (II) UnloadModule: "wacom"
  (II) config/hal: removing device usbhid touch
  (II) UnloadModule: "wacom"
Comment 72 Matthew Rezny freebsd_committer 2017-03-16 11:42:33 UTC
(In reply to Jan Beich (mail not working) from comment #71)

I have not tried the HAL code in years since it did not work for me, but I saw similar with the udev config code active, so I do not believe it specific to the devd backend. With the isParent check in place, X doesn't let go of the input device and thus devd doesn't send the removal notice until I do a VT switch, which interrupts all the inputs. I also noticed that reconnecting the tablet creates a /dev/event/inputX+1 to which another instance of the wacom driver attaches. All the instances stay connected, spamming the log, until VT switch.

The way I understood that comment in UnInit is that newer X server will call UnInit for every child device in correct order whereas old server did not. The old UnInit code checks to see if the device it was handed isParent, and if so it runs through and removes all devices for which isParent is false, i.e. the children. Given that, the check for isParent appears to be in the wrong place. Instead of checking priv->isParent initially, which would only be true if the I/O error occurs while the parent device is attempting a read, check !other->isParent in the for loop.

Unfortunately, this is more complex that it appears at first glance. DeleteInputDeviceRequest is not safe to call here. It looked like it was ok the first time, but most of the time I get multiple backtraces in the log upon disconnect.

[523237.117] (EE) BUG: triggered 'if (in_input_thread())'
[523237.117] (EE) BUG: io.c:656 in WriteToClient()
[523237.118] (EE) ******** WriteToClient called from input thread *********
[523237.118] (EE) 
[523237.118] (EE) Backtrace:
[523237.142] (EE) 0: /usr/local/bin/Xorg (WriteToClient+0x78) [0x5aa0d8]
[523237.162] (EE) 1: /usr/local/bin/Xorg (WriteEventsToClient+0x187) [0x441657]
[523237.184] (EE) 2: /usr/local/bin/Xorg (TryClientEvents+0x1dc) [0x4414bc]
[523237.204] (EE) 3: /usr/local/bin/Xorg (DeliverRawEvent+0x834) [0x442b34]
[523237.225] (EE) 4: /usr/local/bin/Xorg (DeliverEventsToWindow+0x35c) [0x441a5c]
[523237.245] (EE) 5: /usr/local/bin/Xorg (XIGetDevice+0xd58) [0x529bd8]
[523237.266] (EE) 6: /usr/local/bin/Xorg (DisableDevice+0x2d8) [0x42ca08]
[523237.286] (EE) 7: /usr/local/bin/Xorg (RemoveDevice+0xcd) [0x42db9d]
[523237.307] (EE) 8: /usr/local/bin/Xorg (DeleteInputDeviceRequest+0x38) [0x489238]
[523237.327] (EE) 9: /usr/local/lib/xorg/modules/input/wacom_drv.so (_init+0x17f5) [0x811f3a925]
[523237.348] (EE) 10: /usr/local/lib/xorg/modules/input/wacom_drv.so (_init+0x841) [0x811f38a71]
[523237.369] (EE) 11: /usr/local/bin/Xorg (xthread_sigmask+0xee) [0x5a936e]
[523237.389] (EE) 12: /usr/local/bin/Xorg (OsCleanup+0x4cf) [0x5ab51f]
[523237.409] (EE) 13: /usr/local/bin/Xorg (input_force_unlock+0x712) [0x5a9572]
[523237.430] (EE) 14: /lib/libthr.so.3 (_pthread_create+0x915) [0x80256e365]
[523237.450] (EE) 15: ? (?+0x915) [0x915]

It turns out that patching the wacom DDX is not all that practical. The way input is handled was changed in 1.19, now there is an input thread on which the I/O occurs and we can't go removing or disabling device from within the thread, rather we would need to signal across threads. The better way to solve this is at the root of the problem; instead of patching every input driver just fix webcamd so it removes device nodes for disconnected devices.
Comment 73 Matthew Rezny freebsd_committer 2017-03-16 16:40:11 UTC
Created attachment 180880 [details]
update Xorg to 1.19.3 and integrate collective devd enhancements
Comment 74 Vladimir Kondratyev freebsd_committer 2017-03-25 12:44:46 UTC
(In reply to Matthew Rezny from comment #72)
> The way input is handled was changed in 1.19,
> now there is an input thread on which the I/O occurs
> and we can't go removing or disabling device from within
> the thread, rather we would need to signal across threads.

There is other way: Do not remove device on error but only close() its fd. That should break webcamd deadlock and than allow devfs to signal users about cdev destruction. Look at libinput patch that solved webcmd device detach for me:
https://reviews.freebsd.org/differential/changeset/?ref=236295
Comment 75 Vladimir Kondratyev freebsd_committer 2018-03-18 11:57:34 UTC
Created attachment 191592 [details]
update Xorg to 1.19.6 and integrate collective devd enhancements

- Add support for kernels compiled with EVDEV_SUPPORT option enabled.
- Fix bug in evdev type autodetection preventing touchscreen recognition on 64bit arches.
- Patch is rebased on top of current ports tree.
- Xorg version bumped to 1.19.6
- PR/220562 is integrated.
Comment 76 Niclas Zeising freebsd_committer 2018-03-19 17:38:17 UTC
Hi!
Since the patch includes updates to xserver, and a quite major one at that, it will take some time to digest it all.
Comment 77 Jean-Sébastien Pédron freebsd_committer 2018-03-22 15:45:11 UTC
I started to test this patch on my main laptop (which I use daily for work and personal stuff).

I built the X.Org server with udev support and configured xf86-input-libinput (the kernel was already built with evdev). The input part is the laptop's keyboard, an external USB keyboard and an external USB mouse. The video part is the NVIDIA driver (with two external monitors) when at my desk, or  the built-in xf86-video-modesetting (+ Intel GPU) when elsewhere.

The setup is described here:
https://wiki.freebsd.org/Laptops/Gigabyte_Aero_15X

I didn't change anything to start using xorg-server 1.19.x compared to 1.18.x. I will report back in a few days to tell how it went.
Comment 78 Dmitri Goutnik 2018-04-03 01:56:22 UTC
For anyone interested in testing this patch in VirtualBox, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227238
Comment 79 Jean-Sébastien Pédron freebsd_committer 2018-04-04 09:48:33 UTC
After two weeks of using the X.Org server 1.19.6 on my laptop daily for work and personal stuff, I can tell that it works very nicely for me. Nothing wrong to report so far.

Again, my setup:
- running FreeBSD HEAD (updated weekly)
- use both Intel iGPU (Kabylake) + drm-next and NVIDIA dGPU and proprietary driver
- use integrated display + two UHD external monitors (DisplayPort + HDMI)
- use libinput with integrated keyboard + integrated touchpad + USB keyboard + USB mouse
Comment 80 Jean-Sébastien Pédron freebsd_committer 2018-04-11 21:38:23 UTC
Are we ready to commit this patch? Anything left preventing this?

It contains significant fixes and reduces the gap with the upcoming 1.20 release of the X.Org server.

Also, while we work on evdev/libinput in userland, what about enabling EVDEV in HEAD's GENERIC kernel?
Comment 81 pete 2018-04-11 21:53:05 UTC
I'd love both of these things to happen.  I'm actively testing and using drm-next on my systems, and not having to track patches to get updated xorg would be really appreciated.  The same goes for enabling EVDEV in HEAD.
Comment 82 Vladimir Kondratyev freebsd_committer 2018-04-12 00:39:34 UTC
(In reply to Jean-Sébastien Pédron from comment #80)
> Anything left preventing this?
I have been running this since first CFT:
https://lists.freebsd.org/pipermail/freebsd-x11/2017-March/019100.html

It had 2 problems known to me these days:

1. Interference with vt (PR/220562)
2. It attached both legacy and evdev drivers to input devices if kernel was compiled with EVDEV_SUPPORT enabled.

Hopefully, both of them are fixed now.
I never tried modesetting driver and GLAMOR which are claimed to be a major 
improvement of 1.19 version.

> what about enabling EVDEV in HEAD's GENERIC kernel
It can not be enabled by default just now as EVDEV is not reenterable on breaking to DDB.
I have patches addressing this so if someone is willing to enable EVDEV in HEAD's GENERIC they can be reviewed/commited.
Comment 83 Jean-Sébastien Pédron freebsd_committer 2018-04-12 13:07:45 UTC
(In reply to Vladimir Kondratyev from comment #82)
> 1. Interference with vt (PR/220562)

The patch for bug 220562 is included in this patch according to the list of changes (see comment #75).

> 2. It attached both legacy and evdev drivers to input devices if kernel was
> compiled with EVDEV_SUPPORT enabled.

I believe it's still true: for instance, it tries to attach the external keyboard through evdev, ukdb and kbdmux (I only have xf86-input-libinput installed).

> I never tried modesetting driver and GLAMOR which are claimed to be a major
> improvement of 1.19 version.

I'm using xf86-video-modesetting and Glamor when I use the i915 GPU on my laptop and it's working great so far.

> I have patches addressing this so if someone is willing to enable EVDEV in
> HEAD's GENERIC they can be reviewed/commited.

Could you please point us to those patches?
Comment 84 Vladimir Kondratyev freebsd_committer 2018-04-15 00:57:37 UTC
(In reply to Jean-Sébastien Pédron from comment #83)
> Could you please point us to those patches?
https://reviews.freebsd.org/D15070
Comment 85 Jean-Sébastien Pédron freebsd_committer 2018-04-28 10:58:49 UTC
> 2. It attached both legacy and evdev drivers to input devices if kernel was
> compiled with EVDEV_SUPPORT enabled.

I'm trying to that with the following patch to libudev-devd:
https://github.com/FreeBSDDesktop/libudev-devd/pull/5
Comment 86 Jean-Sébastien Pédron freebsd_committer 2018-05-04 21:36:41 UTC
Shall we commit this X.Org update?

I don't know who else tested it but I used it on a Radeon-based laptop and an Intel+NVIDIA one extensively, with EVDEV/libinput. It's working like a charm for months.

So any objection to commit it?
Comment 87 Vladimir Kondratyev freebsd_committer 2018-05-05 11:45:33 UTC
(In reply to Jean-Sébastien Pédron from comment #86)

> I don't know who else tested it

I've been running this update for more than 1 year and have never seen any issues connected to xorg-server itself. I have seen rare lockups in several 3D apps (xorg-screensavers mostly) but it looks like recent drm and mesa changes fixed them. My setups are Intel-based laptop + Legacy NVIDIA desktop both used in everyday life.

Also, I received several private emails with "I tested it and found it working. When it will be commited?"

Also, there were few positive reports after the initial CFT more than year ago:
https://lists.freebsd.org/pipermail/freebsd-x11/2017-March/019100.html
1.19.6 update basically is the same patch as the 1.19.3. The size difference is caused by removal of lots CVE-* patches already committed to 1.19.6 sources.

So I think it has got some testing and hope it will be committed better sooner rather than later.
Comment 88 Vladimir Kondratyev freebsd_committer 2018-05-05 11:51:52 UTC
(In reply to Vladimir Kondratyev from comment #87)
> have never seen any issues connected to xorg-server itself.
Never seen any issues except 2 problems addressed in 1.19.6 update:
1. Interference with vt (PR/220562)
2. Xorg attaches both legacy and evdev drivers if kernel was compiled with EVDEV_SUPPORT enabled.
Comment 89 Ivan 2018-05-05 12:30:34 UTC
How can I test it ?

At the moment I have evdev enabled kernel, Xorg from the ports with VT and UDEV patches. It works flawlessly with libinput.

To test this patch I should compile Xorg with DEVD backend and see how it handles /dev/input nodes, right?
Comment 90 Vladimir Kondratyev freebsd_committer 2018-05-05 12:57:07 UTC
(In reply to Ivan from comment #89)
> How can I test it ?

1. Revert previous UDEV patches
2. Apply PR/196678 patch
3. Rebuild Xorg and all xf86-drivers. Try both DEVD and UDEV options
4. Run xorg for some time. If your kernel is built with EVDEV_SUPPORT enabled run xinput and xev to ensure that events produced by input devices are not duplicated and no glitches appear on screen while typing.
Comment 91 Ivan 2018-05-13 15:57:14 UTC
I've found no issues, devd backend correctly picks up /dev/input of EVDEV enabled kernel, legacy keyboard and mouse driver are not attached.

However, Option "XkbRules" "evdev" is still required for arrow keys.
Comment 92 Vladimir Kondratyev freebsd_committer 2018-08-05 19:26:30 UTC
Created attachment 195909 [details]
update Xorg to 1.19.6 and integrate collective devd enhancements

The patch is rebased on top of recent xproto changes. Poudriere-only tested.
Comment 93 Vladimir Kondratyev freebsd_committer 2018-08-09 22:12:44 UTC
Created attachment 196037 [details]
update Xorg to 1.19.6 and integrate collective devd enhancements

Fix tigervnc build with Xorg 1.19
Comment 94 voidanix 2018-09-22 21:09:42 UTC
How is this going? It's a 3 years old "bug" and we should update to 1.20 someday too, right?
Comment 95 Vladimir Kondratyev freebsd_committer 2018-09-23 11:15:43 UTC
(In reply to voidanix from comment #94)
> we should update to 1.20 someday too, right?

Unfortunately, 1.20 modesetting driver is suffering from lockups being run on top of our 4.15+ drm kmod.
Comment 96 Oleh Hushchenkov 2018-09-23 15:38:27 UTC
It would be great if this will be committed.
Comment 97 pete 2018-09-23 18:44:20 UTC
(In reply to Vladimir Kondratyev from comment #95)
if there is a set of patches available to test out 1.20 i would love the help squash any bugs we are running into regarding the drm-*-kmod drivers.  would you mind pointing me in the right direction?
Comment 98 Vladimir Kondratyev freebsd_committer 2018-09-23 22:57:40 UTC
Created attachment 197417 [details]
update Xorg to 1.20.1 and integrate collective devd enhancements

> if there is a set of patches available to test out 1.20
Patch attached

Xorg freezes for me right after some programs e.g. firefox have been run if modesetting driver is used along with drm-devel-kmod (4.15-4.17). 4.9 and 4.11 drms are OK.

It also has a knob to workaround the freeze.
Comment 99 Kurt Jaeger freebsd_committer 2018-10-26 22:26:52 UTC
There's this one-liner security issue:

https://twitter.com/hackerfantastic/status/1055517801224396800

Did anyone check the current port or this update ?
Comment 100 Niclas Zeising freebsd_committer 2018-10-27 08:15:31 UTC
(In reply to Kurt Jaeger from comment #99)

The version currently in FreeBSD ports is not vulnerable.
Comment 101 Vladimir Kondratyev freebsd_committer 2018-10-27 23:49:33 UTC
Created attachment 198703 [details]
update Xorg to 1.20.3 and integrate collective devd enhancements

Handle CVE-2018-14665
Comment 102 Koichiro Iwao freebsd_committer 2018-11-12 14:40:07 UTC
Looks like dependency is reversed?
Comment 103 Koichiro Iwao freebsd_committer 2018-11-16 02:29:00 UTC
I don't think this blocks 233044. Closed.
Comment 104 Niclas Zeising freebsd_committer 2018-11-16 06:16:39 UTC
Hi!
I'd like to wait with this until pr222905, which is in progress, is committed.
Comment 105 Jean-Sébastien Pédron freebsd_committer 2018-12-27 20:43:41 UTC
This patch stopped working with the latest update to libevdev/libinput/xf86-input-libinput :(


Here is what I get for all input devices in Xorg.0.log:

[  3092.801] (II) config/udev: Adding input device ETPS/2 Elantech Touchpad (/dev/input/event3)
[  3092.801] (II) Using input driver 'libinput' for 'ETPS/2 Elantech Touchpad'
[  3092.801] (**) ETPS/2 Elantech Touchpad: always reports core events
[  3092.801] (**) Option "Device" "/dev/input/event3"
[  3092.801] (**) Option "_source" "server/udev"
[  3092.917] (II) input device 'ETPS/2 Elantech Touchpad', /dev/input/event3 is tagged by udev as: Mouse Touchpad
[  3092.917] (II) input device 'ETPS/2 Elantech Touchpad', /dev/input/event3 is a touchpad
[  3092.952] (**) Option "Tapping" "on"
[  3092.952] (**) Option "ClickMethod" "clickfinger"
[  3092.952] (**) Option "config_info" "udev:/dev/input/event3"
[  3092.952] (II) XINPUT: Adding extended input device "ETPS/2 Elantech Touchpad" (type: TOUCHPAD, id 6)
[  3092.952] (**) Option "AccelerationScheme" "none"
[  3092.952] (**) ETPS/2 Elantech Touchpad: (accel) selected scheme none/0
[  3092.952] (**) ETPS/2 Elantech Touchpad: (accel) acceleration factor: 2.000
[  3092.952] (**) ETPS/2 Elantech Touchpad: (accel) acceleration threshold: 4
[  3093.068] (II) input device 'ETPS/2 Elantech Touchpad', /dev/input/event3 is tagged by udev as: Mouse Touchpad
[  3093.068] (II) input device 'ETPS/2 Elantech Touchpad', /dev/input/event3 is a touchpad
[  3093.104] (II) failed to create input device '/dev/input/event3'.
[  3093.104] [dix] couldn't enable device 6
[  3093.104] (EE) Couldn't init device "ETPS/2 Elantech Touchpad"
[  3093.104] (II) UnloadModule: "libinput"

The laptop is currently running r342164. I'm updating the kernel as we speak just in case.
Comment 106 Vladimir Kondratyev freebsd_committer 2018-12-27 21:34:41 UTC
(In reply to Jean-Sébastien Pédron from comment #105)
> This patch stopped working with the latest update to
> libevdev/libinput/xf86-input-libinput :(

Try to revert epoll-shim back to 2016XXXX version.

One of my boxes has a similar issue. I don't know why others not. May be it is a nvidia-legacy video driver - connected bug.
Comment 107 Jean-Sébastien Pédron freebsd_committer 2018-12-27 22:41:58 UTC
I confirm that reverting devel/libepoll-shim back to 0.0.20161220_1 fixes the issue: input devices work as expected!

Thank you for unblocking me so fast :)
Comment 108 pete 2019-02-05 04:23:51 UTC
(In reply to Vladimir Kondratyev from comment #101)
Hi there, it looks like the ports tree has moved forward enough where this patch won't apply cleanly anymore.  I've started to work through it, but I haven't made much progress.  

I've identified these failure to patch issues:

1) net/tigervnc/Makefile:

|Index: net/tigervnc/Makefile
|===================================================================
|--- net/tigervnc/Makefile      (revision 483043)
|+++ net/tigervnc/Makefile      (working copy)
--------------------------
Patching file net/tigervnc/Makefile using Plan A...
Hunk #1 succeeded at 33 with fuzz 1 (offset -1 lines).
Hunk #2 failed at 107.


-- I've taken an initial look at this and am unsure as to the best course of action to move forward.  it looks like the Makefile was updated to automagically determine the xorg-server version?

2) x11-server/xorg-server/Makefile

|Index: x11-servers/xorg-server/Makefile
|===================================================================
|--- x11-servers/xorg-server/Makefile   (revision 483043)
|+++ x11-servers/xorg-server/Makefile   (working copy)
--------------------------
Patching file x11-servers/xorg-server/Makefile using Plan A...
Hunk #1 failed at 2.
Hunk #2 succeeded at 21.
Hunk #3 succeeded at 68.
Hunk #4 succeeded at 83.
Hunk #5 succeeded at 93.


-- This is easy enough, just a bump of PORTREVISION from "10" to "11"


2) x11-servers/xorg-server/files/patch-glamor_glamor__dash.c

--------------------------
|Index: x11-servers/xorg-server/files/patch-glamor_glamor__dash.c
|===================================================================
|--- x11-servers/xorg-server/files/patch-glamor_glamor__dash.c  (revision 483043)
|+++ x11-servers/xorg-server/files/patch-glamor_glamor__dash.c  (nonexistent)
--------------------------
Patching file x11-servers/xorg-server/files/patch-glamor_glamor__dash.c using Plan A...
Empty context always matches.
Hunk #1 failed at 0.


-- Not sure why this deletion is not working tbh.


3) x11-servers/xwayland/Makefile

|Index: x11-servers/xwayland/Makefile
|===================================================================
|--- x11-servers/xwayland/Makefile      (revision 483043)
|+++ x11-servers/xwayland/Makefile      (working copy)
--------------------------
Patching file x11-servers/xwayland/Makefile using Plan A...
Hunk #1 failed at 1.

-- this is pretty trivial but haven't had a chance to update patch accordingly.  we've just added some comments and a PORTREVISION line to the Makefile.


Hope this helps someone if they can get to this before me :)
Comment 109 Vladimir Kondratyev freebsd_committer 2019-03-23 23:30:26 UTC
Created attachment 203086 [details]
update Xorg to 1.20.4 and integrate collective devd enhancements

Update xorg to 1.20.4 rebase on top of current ports tree
Comment 110 Niclas Zeising freebsd_committer 2019-03-24 00:23:59 UTC
See work in progress and testing at https://github.com/FreeBSDDesktop/freebsd-ports/tree/feature/xserver-1.20