Bug 196678

Summary: x11-servers/xorg-server: Update to 1.20.7 + make config/devd recognize /dev/input/eventX from multimedia/webcamd
Product: Ports & Packages Reporter: Hans Petter Selasky <hselasky>
Component: Individual Port(s)Assignee: freebsd-x11 mailing list <x11>
Status: Closed FIXED    
Severity: Affects Some People CC: 0mp, FreeBSD, Lena, ak, aksyom, andrelupa, arrowd, avg, bsd, dmgk, doctorwhoguy, dumbbell, emaste, freebsd-ports, freebsdbugs, greg, gregf, grembo, henry.hu.sh, iwtcex, jakob, jbeich, kwm, lukebenes, lwhsu, manu, markj, meta, ml+freebsd, nox, o.hushchenkov, pete, pi, portmaster, rezny, rk, rozhuk.im, sdalu, sergey.dyatko, seschwar, shadow53+freebsd, sigsys, trueos, vmagerya, voidanix, wulf, x11max1, zeising
Priority: --- Keywords: feature, patch
Version: Latest   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200938
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220562
Bug Depends on: 196978, 220562, 244129    
Bug Blocks: 244242    
Attachments:
Description Flags
Updated devd backend patch
none
updates to devd backend in diff form.
none
Devd patch for Xorg server
none
Devd file for Xorg server
none
Devd patch for Xorg server
none
Devd file for Xorg server
none
makes devd to hanle all known input devices
none
Xorg.0.log entries of wacom device
none
makes devd to hanle all known input devices and unknown in /dev/input/
rozhuk.im: maintainer-approval+
makes devd to hanle all known input devices and unknown in /dev/input/
none
patch-config_devd.c with device type autodetection
none
devd: support webcamd, evdev, uhid, all from /dev/input
none
devd: support webcamd, evdev, uhid, all from /dev/input
none
update Xorg to 1.19.2 and integrate collective devd enhancements
none
wacom plug/unplug log with different drivers
none
update Xorg to 1.19.3 and integrate collective devd enhancements
none
update Xorg to 1.19.6 and integrate collective devd enhancements
none
update Xorg to 1.19.6 and integrate collective devd enhancements
none
update Xorg to 1.19.6 and integrate collective devd enhancements
none
update Xorg to 1.20.1 and integrate collective devd enhancements
none
update Xorg to 1.20.3 and integrate collective devd enhancements
none
update Xorg to 1.20.4 and integrate collective devd enhancements
none
update Xorg to 1.20.6 and integrate collective devd enhancements
none
update Xorg to 1.20.7 and integrate collective devd enhancements
none
update Xorg to 1.20.7 and integrate collective devd enhancements
none
update Xorg to 1.20.7 and integrate collective devd enhancements
none
update Xorg to 1.20.7 and ingegrate patches
none
restore xf86DisableRandR none

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 freebsd_committer 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
Comment 111 Ivan 2019-06-02 09:42:44 UTC
Do you have hot plug working with DEVD backend ?  I use USB KVM to share keyboard and mouse between 2 computers and looks like libinput not loading after devices return.

Devices removed: 

[  6480.122] (II) config/devd: removing nonexistent device /dev/ukbd0
[  6480.122] (II) config/devd: removing input device /dev/input/event3
[  6480.122] (II) config/devd: removing device vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 22
[  6480.122] (II) event3  - vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 22: device removed
[  6480.123] (II) UnloadModule: "libinput"
[  6480.163] (II) config/devd: removing nonexistent device /dev/uhid0
[  6480.164] (II) config/devd: removing nonexistent device /dev/uhid1
[  6480.166] (II) config/devd: removing nonexistent device /dev/ukbd1
[  6480.166] (II) config/devd: removing input device /dev/input/event4
[  6480.166] (II) config/devd: removing device Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 24
[  6480.166] (II) event4  - Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 24: device removed
[  6480.166] (II) UnloadModule: "libinput"
[  6480.166] (II) config/devd: removing nonexistent device /dev/ums0
[  6480.184] (II) config/devd: removing input device /dev/input/event5
[  6480.184] (II) config/devd: removing device Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 24
[  6480.184] (II) event5  - Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 24: device removed
[  6480.185] (II) UnloadModule: "libinput"
[  6480.185] (II) config/devd: removing nonexistent device /dev/uhid2


Devices returned back:

[  6504.086] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device ukbd0
[  6504.086] (II) config/devd: detected event input: vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 28, bustype=0003, vendor=046d, product=c221, version=0000
[  6504.086] (II) config/devd: adding input device /dev/input/event3
[  6504.086] (**) vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 28: Applying InputClass "libinput keyboard catchall"
[  6504.086] (**) vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 28: Applying InputClass "Evdev keyboard XkbRules"
[  6504.086] (II) Using input driver 'libinput' for 'vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 28'
[  6504.087] (**) vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 28: always reports core events
[  6504.087] (**) Option "Device" "/dev/input/event3"
[  6504.087] (**) Option "_source" "server/devd"
[  6504.089] (II) event3  - vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 28: is tagged by udev as: Keyboard
[  6504.089] (II) event3  - vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 28: device is a keyboard
[  6504.090] (II) event3  - failed to create input device '/dev/input/event3'.
[  6504.090] (EE) libinput: vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 28: Failed to create a device for /dev/input/event3
[  6504.090] (EE) PreInit returned 2 for "vendor 0x046d Gaming Keyboard, class 0/0, rev 2.00/1.90, addr 28"
[  6504.090] (II) UnloadModule: "libinput"
[  6504.090] (EE) config/devd: error 2 adding device /dev/input/event3
[  6504.124] (II) config/devd: detected USB HID of unknown type
[  6504.124] (II) config/devd: [sysctl] usb_id: 0x046d:0xc221
[  6504.124] (II) config/devd: [sysctl] vendor: vendor, product: 0x046d Gaming Keyboard
[  6504.124] (II) config/devd: adding input device /dev/uhid0
[  6504.124] (II) No input driver specified, ignoring this device.
[  6504.124] (II) This device may have been added with another device file.
[  6504.124] (EE) config/devd: error 1 adding device /dev/uhid0
[  6504.732] (II) config/devd: detected USB HID of unknown type
[  6504.732] (II) config/devd: [sysctl] usb_id: 0x046d:0xc222
[  6504.732] (II) config/devd: [sysctl] vendor: G15, product: Keyboard G15 Keyboard
[  6504.732] (II) config/devd: adding input device /dev/uhid1
[  6504.732] (II) No input driver specified, ignoring this device.
[  6504.732] (II) This device may have been added with another device file.
[  6504.733] (EE) config/devd: error 1 adding device /dev/uhid1
[  6505.382] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device ukbd1
[  6505.382] (II) config/devd: detected event input: Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30, bustype=0003, vendor=046d, product=c52b, version=0000
[  6505.382] (II) config/devd: adding input device /dev/input/event4
[  6505.382] (**) Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: Applying InputClass "libinput keyboard catchall"
[  6505.382] (**) Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: Applying InputClass "Evdev keyboard XkbRules"
[  6505.383] (II) Using input driver 'libinput' for 'Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30'
[  6505.383] (**) Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: always reports core events
[  6505.383] (**) Option "Device" "/dev/input/event4"
[  6505.383] (**) Option "_source" "server/devd"
[  6505.385] (II) event4  - Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: is tagged by udev as: Keyboard
[  6505.385] (II) event4  - Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: device is a keyboard
[  6505.385] (II) event4  - failed to create input device '/dev/input/event4'.
[  6505.385] (EE) libinput: Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: Failed to create a device for /dev/input/event4
[  6505.385] (EE) PreInit returned 2 for "Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30"
[  6505.385] (II) UnloadModule: "libinput"
[  6505.385] (EE) config/devd: error 2 adding device /dev/input/event4
[  6505.387] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device ums0
[  6505.426] (II) config/devd: detected event input: Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30, bustype=0003, vendor=046d, product=c52b, version=0000
[  6505.426] (II) config/devd: adding input device /dev/input/event5
[  6505.426] (**) Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: Applying InputClass "libinput pointer catchall"
[  6505.426] (II) Using input driver 'libinput' for 'Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30'
[  6505.426] (**) Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: always reports core events
[  6505.426] (**) Option "Device" "/dev/input/event5"
[  6505.426] (**) Option "_source" "server/devd"
[  6505.428] (II) event5  - Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: is tagged by udev as: Mouse
[  6505.428] (II) event5  - Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: device is a pointer
[  6505.428] (II) event5  - failed to create input device '/dev/input/event5'.
[  6505.428] (EE) libinput: Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30: Failed to create a device for /dev/input/event5
[  6505.428] (EE) PreInit returned 2 for "Logitech USB Receiver, class 0/0, rev 2.00/12.03, addr 30"
[  6505.428] (II) UnloadModule: "libinput"
[  6505.429] (EE) config/devd: error 2 adding device /dev/input/event5
[  6505.429] (II) config/devd: detected USB HID of unknown type
[  6505.429] (II) config/devd: [sysctl] usb_id: 0x046d:0xc52b
[  6505.429] (II) config/devd: [sysctl] vendor: Logitech, product: USB Receiver
[  6505.429] (II) config/devd: adding input device /dev/uhid2
[  6505.429] (II) No input driver specified, ignoring this device.
[  6505.429] (II) This device may have been added with another device file.
[  6505.429] (EE) config/devd: error 1 adding device /dev/uhid2

This is with xf86-input-libinput.
Legacy input drivers (-keyboard and -mouse) works.

Strange I didn't find similar questions.
Comment 112 Ivan 2019-06-02 09:48:39 UTC
I have Xorg 1.19.6 patch though, maybe it was fixed with recent one?
Comment 113 rozhuk.im 2019-06-26 21:22:16 UTC
Looks like last devd backend does not work properly.

options 	EVDEV_SUPPORT		#o evdev support in legacy drivers
device		evdev			#m input event device support
device		uinput			#m install /dev/uinput cdev

Mouse does not work with 1.20.4.
Then I remove options EVDEV_SUPPORT, but devd continue ignore ums* devices.
For now I remove that 3 lines from kernel and all works fine.
Comment 114 Hans Petter Selasky freebsd_committer 2019-06-27 07:34:48 UTC
There are some sysctls you need to configure aswell, and you need the input-evdev for x86 installed. Can you check?

--HPS
Comment 115 rozhuk.im 2019-06-27 10:40:06 UTC
xf86-input-evdev-2.10.6_4 installed.
I rebuild all ports that depend on xorg after update.
With xorg-server-1.19.6 all works with same configs.
Probably xorg-macros-1.19.2 or xf86-input-evdev-2.10.6 need update for work with 1.20.4.

Also devd backend must be updated to support "OutputClass" - GPU device detection. I will try fix this.
Comment 116 Vladimir Kondratyev freebsd_committer 2019-06-27 18:58:25 UTC
(In reply to rozhuk.im from comment #115)
> Probably xorg-macros-1.19.2 or xf86-input-evdev-2.10.6 need update for work with 1.20.4.

I just tested xf86-input-evdev-2.10.6 with xorg-server 1.20.4 and found it compatible. At least in my setup.
So I would recommend examine /var/log/Xorg.0.log for error messages
Comment 117 Ivan 2019-10-13 18:37:12 UTC
I think I can confirm issue with hot plug. I updated FreeBSD to 12.1-RC1 and Xorg to 1.20.4 and if I unplug-plug USB Logitech mouse receiver Xorg can't reattach to it.

event5 - failed to create input device '/dev/input/event5'

Receiver works in console (if I Ctrl + Alt to it) or after Xorg restart.

Receiver works if it plugged after Xorg start, so only removal breaks something.
Comment 118 rozhuk.im 2019-11-01 21:46:06 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241650
x11-drivers/xf86-video-scfb: remove LoaderGetOS()
Comment 119 rozhuk.im 2019-11-01 22:37:13 UTC
Few tips/bugs:

1. I have 1.20.4 and kernel with:
options 	EVDEV_SUPPORT		#o evdev support in legacy drivers
device		evdev			#m input event device support
device		uinput			#m install /dev/uinput cdev

xf86-input-evdev-2.10.6_4          =   up-to-date with index
xf86-input-joystick-1.6.3_2        =   up-to-date with index
xf86-input-keyboard-1.9.0_3        =   up-to-date with index
xf86-input-libinput-0.28.2         =   up-to-date with index
xf86-input-mouse-1.9.3_2           =   up-to-date with index
xf86-input-synaptics-1.9.1_4       =   up-to-date with index
xf86-input-wacom-0.38.0            =   up-to-date with index


a) Mouse does not work with "libinput" (xorg def driver), "evdev" and "mouse" until
sysctl kern.evdev.rcpt_mask=65535 (default is 3; yes, I know about only 4 bits in this sysctl)

b) Only with "libinput" VBOX does not capture/release pointer, but mouse work ok.

c) Keyboard arrows does not work proper with "libinput" driver, probably xkb_layout does not apply.

d) I see on notebook issue: after reload touchpad driver "libinput" cant attach to it. Have no time to debug it yet.


2. emulators/virtualbox-ose-additions build fail, until remove "_X_NOTSAN" in:
/usr/local/include/xorg/dix.h
static inline _X_NOTSAN Bool
Comment 120 Jan Beich freebsd_committer 2019-11-02 01:13:50 UTC
(In reply to rozhuk.im from comment #119)
> c) Keyboard arrows does not work proper with "libinput" driver, probably xkb_layout does not apply.

libinput uses evdev(4) under the hood, so you may need to adjust XkbRules e.g.,

Section "InputClass"
	Identifier "keyboard defaults"
	MatchIsKeyboard "true"
	Option "XkbRules" "evdev"
EndSection
Comment 121 rozhuk.im 2019-11-02 01:20:46 UTC
(In reply to Jan Beich from comment #120)

Thanks, I "fix" it by using

Section "InputClass"
	Identifier	"Keyboard"
	MatchIsKeyboard	"true"
	Driver		"evdev"
	Option		"XkbLayout" "us,ru(winkeys)"
	Option		"XkbOptions" "grp:ctrl_shift_toggle"
EndSection

Driver		"kbd" - work too.

For mouse:

Section "InputClass"
	Identifier	"Mouse"
	MatchIsPointer	"true"
	Driver		"evdev"
	Option		"Protocol" "auto"
	Option		"ZAxisMapping" "4 5 6 7"
EndSection
Comment 122 Vladimir Kondratyev freebsd_committer 2019-11-24 11:56:47 UTC
Created attachment 209380 [details]
update Xorg to 1.20.6 and integrate collective devd enhancements

Update Xorg to 1.20.6 and rebase patch on top of current ports tree
Comment 123 Niclas Zeising freebsd_committer 2019-11-25 10:39:23 UTC
(In reply to Vladimir Kondratyev from comment #122)

Thanks for the new patch!
I'll incorporate it into our dev tree asap.
Comment 125 Vladimir Kondratyev freebsd_committer 2020-02-13 20:10:53 UTC
Created attachment 211620 [details]
update Xorg to 1.20.7 and integrate collective devd enhancements

Update Xorg to 1.20.7 and rebase patch on top of the current ports tree
Comment 126 Emmanuel Vadot freebsd_committer 2020-02-17 15:56:14 UTC
(In reply to Jan Beich from comment #120)

This is also needed when using the xf86-input-keyboard driver, well, when you think that you're using it as you didn't set any permission to /dev/input/event*. 
Since Xorg is suid if will use those devices.
So that patch also deprecates xf86-input-mouse and xf86-input-keyboard (for someone using GENERIC) which is fine for me.
And since xf86-input-libinput is in the meta package xorg-drivers it should be installed on most machine and if it isn't, it's easy to fix a broken config after upgrading xorg by installing it.

Wulf: could you add this snippet to /usr/local/share/X11/xorg.conf.d/20-kdb.conf and install this file ?
Or maybe find why it's behaving like this (I'm not familiar with xorg internals).

Otherwise the patch is ok for me and tested on 13 amd64, I'm waiting for my build to finish for 12.1

This should be commited rather sooner than later as I'd like to have it in the next quarterly run (April) and having a full month to debug possible issues.
Comment 127 Jan Beich freebsd_committer 2020-02-17 16:23:53 UTC
(In reply to Emmanuel Vadot from comment #126)
> Or maybe find why it's behaving like this

See bug 244129 which can be applied to xorg-server instead. A similar change would need to be done in libxkbcommon, eliminating one step of configuration for Wayland users.
Comment 128 Emmanuel Vadot freebsd_committer 2020-02-17 16:37:29 UTC
(In reply to Jan Beich from comment #127)

Ok I see. That might not work with 11.3 since it doesn't have evdev(4).
But maybe in that case Xorg fallback to !evdev if no evdev input module is used ? Or maybe evdev xkb rules works fine everywhere ?
Comment 129 Vladimir Kondratyev freebsd_committer 2020-02-17 20:01:57 UTC
(In reply to Emmanuel Vadot from comment #126)
> Wulf: could you add this snippet to /usr/local/share/X11/xorg.conf.d/20-kdb.conf and install this file ?
I'll do it ASAP
> Or maybe find why it's behaving like this
> (I'm not familiar with xorg internals).
Default kbd rule for autoconfiguration backends like UDEV and DEVD is hardcoded into hw/xfree86/common/xf86Config.c. It points to "evdev" for Linux and to "base" for others. IMHO it is too rough tunable. I don't know if kbd rule fine tuning is possible at Xorg source file level.
Comment 130 Vladimir Kondratyev freebsd_committer 2020-02-18 10:32:36 UTC
Created attachment 211740 [details]
update Xorg to 1.20.7 and integrate collective devd enhancements

1. Set kbd rules are to "evdev" for each autodetected keyboard with extra xorg.conf.d file
2. Fix building of emulators/virtualbox-ose-additions
Comment 131 Emmanuel Vadot freebsd_committer 2020-02-18 11:13:36 UTC
(In reply to Vladimir Kondratyev from comment #130)

Thanks, start build to test again on 13 and 12.1 (didn't have the change to test the older patch on 12.1 yet).
Comment 132 Vladimir Kondratyev freebsd_committer 2020-02-18 11:45:12 UTC
There is one known issue with this patch.

It can't properly detect PS/2 mouse in default 12.1 install.
One must add moused_enable="YES" to /etc/rc.conf or kern.evdev.rcpt_mask=12 to /etc/sysctl.conf to make it working. Otherwise Xorg will listen to silent devices.
Comment 133 Greg V 2020-02-18 12:07:26 UTC
(In reply to Vladimir Kondratyev from comment #132)
Maybe it's time to change the default mask already..

Or invent a new mechanism instead of the mask: e.g. when a driver's evdev device is open, it doesn't forward events to the virtual/multiplexed device.
With that scheme, all drivers should work everywhere out of the box.
Comment 134 Vladimir Kondratyev freebsd_committer 2020-02-18 12:32:35 UTC
(In reply to Greg V from comment #133)
> Maybe it's time to change the default mask already..

I think we can ignore this issue. We really have this setup already broken on 12.1.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238491
Comment 135 Emmanuel Vadot freebsd_committer 2020-02-18 16:07:09 UTC
(In reply to Vladimir Kondratyev from comment #130)

One thing I've noted in a fresh install test is that xf86-input-libinput isn't installed by default, and we need this now.
The xorg-drivers meta-package should install it.
Also if I leave the kern.evdev.rcpt_mask to 3 I have keyboard but no mouse. Starting moused solve the problem (patch in PR 238491 doesn't help).
So maybe it's really time to change the default mask. At least we should have this info noted in pkg-message.
Will test on 12.1 soon-ish
Comment 136 Emmanuel Vadot freebsd_committer 2020-02-18 17:31:13 UTC
(In reply to Emmanuel Vadot from comment #135)

Exact same thing on 12.1
We need to have this "breakage" anyway at one point. We cannot afford waiting for 13.0 or 12.2 to switch everyone to using evdev(4).
Otherwise looks very good and again we should commit this rather sooner than later.
wulf: Could you update again to add some pkg-message that says to set rcpt_mask to 12 for >=12 ?
Thanks a lot for working on this.
Comment 137 Vladimir Kondratyev freebsd_committer 2020-02-18 20:04:39 UTC
Created attachment 211748 [details]
update Xorg to 1.20.7 and integrate collective devd enhancements

Add pkg-message with advice to set kern.evdev.rcpt_mask sysctl value to 6.

Feel free to improve it's wording.
Comment 138 Vladimir Kondratyev freebsd_committer 2020-02-18 20:21:24 UTC
(In reply to Emmanuel Vadot from comment #136)
> We need to have this "breakage" anyway at one point.
> We cannot afford waiting for 13.0 or 12.2 to switch everyone to using evdev(4).
Moused-less PS/2 setup is already broken in 12.1 for touchpads so it is a fix rather than breakage.

> wulf: Could you update again to add some pkg-message that says to set rcpt_mask to 12 for >=12 ?
I added advice to set rcpt_mask to 6. Setting it to 12 can break hyperv keyboard in xorg as previous does not support evdev. Never tried FreeBSD on hyperv, it is only thoughts.

> Thanks a lot for working on this.
It is mrezny@ who assembled several patches in one big pack. But did not commit it for unknown reasons.
Comment 139 Niclas Zeising freebsd_committer 2020-02-18 20:47:38 UTC
Created attachment 211749 [details]
update Xorg to 1.20.7 and ingegrate patches

Hi!
Wulf, thank you very much for your work on this!
I've taken your patch and integrated it with some of my WIPs I've had laying around in the FreeBSDDesktop git repo.
Some highlights of the differences (in no particular order)
* Add xf86-input-libinput to the default set of installed drivers.
* Remove HAL option from xorg-server.  It's been deprecated a long time, it's time to remove it completely.
* Enable UDEV backend by default on FreeBSD 12 and 13.  FreeBSD 11 still uses the DEVD backend.
* Don't use the local glamor fix, rather use the upstream one.

I took the liberty of rewording your pkg-message somewhat.
I also integrated PR 244129 from jbeich, enabling evdev xkb rules by default in xwayland.

Thank you once again for being patient and working on this, even when I haven't been as responsive as I should have.  Hopefully we can push this over the finish line now.

I have one question, between your 1.20.3 patch and the 1.20.4 patch, there's some changes to the patch for the devd backend, are these intentional?  I can't see the change mentioned anywhere.  There's an ioctl and a bunch of defines that are removed.



Speaking of the rcpt_mask and stuff like that.  When I enabled evdev in the default kernel, and also enabled synaptics and elantech support by default, I missed to change the value of that sysctl as well.  We should probably change the default of it to give sane defaults when running FreeBSD as a desktop.  I don't know if this warrants more discussion, or it's just one of those "let's just do it".
Comment 140 Vladimir Kondratyev freebsd_committer 2020-02-18 21:35:25 UTC
(In reply to Niclas Zeising from comment #139)
> * Don't use the local glamor fix, rather use the upstream one.
It did not help me when I tried it. But my glamor bug can be a xfwm-4.12 bug as I can not reproduce it on current xfwm-4.14.

> between your 1.20.3 patch and the 1.20.4 patch, there's some changes to the patch for the devd backend
> There's an ioctl and a bunch of defines that are removed.
AFAIR, I replaced a bunch of constants and ioctls with single #include <dev/evdev/evdev.h> after 10.x branch had been EOL-ed.

> I don't know if this warrants more discussion, or it's just one of those "let's just do it".
+1 for "Just do it"
Comment 141 commit-hook freebsd_committer 2020-02-20 21:16:05 UTC
A commit references this bug:

Author: zeising
Date: Thu Feb 20 21:15:58 UTC 2020
New revision: 526589
URL: https://svnweb.freebsd.org/changeset/ports/526589

Log:
  Update xorg x11 servers to 1.20.7

  Update xorg x11 servers to 1.20.7.  This updates x11-servers/xorg-server,
  xephyr, xorg-dmx, xorg-nestserver, xorg-vbserver and xwayland.

  Enable the UDEV backend by default, instead of the DEVD backend, for
  autoconfiguration of input devices on FreeBSD 12 and later.
  FreeBSD 11 lacks the needed support in base and will keep on using the DEVD
  backend.
  Support for the HAL backend is dropped completely, it has been deprecated
  for a long time.
  Update and improve the DEVD backend.
  Add a pkg message about sysctl configuration that might be needed when using
  UDEV.

  Use the upstream fix for glamour issues.

  Use evdev xkb rules by default in xwayland [2]

  Add x11-drivers/xf86-input-libinput to the list installed by default by
  x11-drivers/xorg-drivers.

  Fix net/tigervnc-server and emulators/virtualbox-ose

  Bump portrevision of all x11 drivers, as well as other ports dependent on
  xorg-server.

  This represents work by many people over a long period.  These include
  wulf, ak, dumbbell, hselasky pete AT nomadlogic DOT org, jbeich, manu,
  myself and possibly others (I tried to look through history, but might have
  missed people. If so, I am sorry.)

  PR:             196678 [1], 244129 [2]
  Submitted by:   hselasky, wulf [1], jbeich [2]
  Obtained from:	https://github.com/FreeBSDDesktop/freebsd-ports/tree/feature/xserver-1.20 (in part)

Changes:
  head/deskutils/easystroke/Makefile
  head/emulators/virtualbox-ose/Makefile
  head/emulators/virtualbox-ose/files/patch-src_VBox_Additions_x11_vboxmouse_Makefile.kmk
  head/emulators/virtualbox-ose-additions/Makefile
  head/net/tigervnc-server/Makefile
  head/net/tigervnc-server/Makefile.common.mk
  head/net/tigervnc-server/files/patch-unix_xserver_hw_vnc_xvnc.c
  head/x11/nvidia-driver/Makefile
  head/x11/nvidia-driver-304/Makefile
  head/x11/nvidia-driver-340/Makefile
  head/x11/nvidia-driver-390/Makefile
  head/x11/slim/Makefile
  head/x11-drivers/xf86-input-egalax/Makefile
  head/x11-drivers/xf86-input-elographics/Makefile
  head/x11-drivers/xf86-input-evdev/Makefile
  head/x11-drivers/xf86-input-joystick/Makefile
  head/x11-drivers/xf86-input-keyboard/Makefile
  head/x11-drivers/xf86-input-libinput/Makefile
  head/x11-drivers/xf86-input-mouse/Makefile
  head/x11-drivers/xf86-input-synaptics/Makefile
  head/x11-drivers/xf86-input-vmmouse/Makefile
  head/x11-drivers/xf86-input-void/Makefile
  head/x11-drivers/xf86-input-wacom/Makefile
  head/x11-drivers/xf86-video-amdgpu/Makefile
  head/x11-drivers/xf86-video-apm/Makefile
  head/x11-drivers/xf86-video-ark/Makefile
  head/x11-drivers/xf86-video-ast/Makefile
  head/x11-drivers/xf86-video-ati/Makefile
  head/x11-drivers/xf86-video-ati-legacy/Makefile
  head/x11-drivers/xf86-video-chips/Makefile
  head/x11-drivers/xf86-video-cirrus/Makefile
  head/x11-drivers/xf86-video-dummy/Makefile
  head/x11-drivers/xf86-video-geode/Makefile
  head/x11-drivers/xf86-video-glint/Makefile
  head/x11-drivers/xf86-video-i128/Makefile
  head/x11-drivers/xf86-video-i740/Makefile
  head/x11-drivers/xf86-video-intel/Makefile
  head/x11-drivers/xf86-video-mach64/Makefile
  head/x11-drivers/xf86-video-mga/Makefile
  head/x11-drivers/xf86-video-neomagic/Makefile
  head/x11-drivers/xf86-video-nv/Makefile
  head/x11-drivers/xf86-video-openchrome/Makefile
  head/x11-drivers/xf86-video-qxl/Makefile
  head/x11-drivers/xf86-video-r128/Makefile
  head/x11-drivers/xf86-video-rendition/Makefile
  head/x11-drivers/xf86-video-s3/Makefile
  head/x11-drivers/xf86-video-s3virge/Makefile
  head/x11-drivers/xf86-video-savage/Makefile
  head/x11-drivers/xf86-video-scfb/Makefile
  head/x11-drivers/xf86-video-siliconmotion/Makefile
  head/x11-drivers/xf86-video-sis/Makefile
  head/x11-drivers/xf86-video-sunffb/Makefile
  head/x11-drivers/xf86-video-tdfx/Makefile
  head/x11-drivers/xf86-video-trident/Makefile
  head/x11-drivers/xf86-video-tseng/Makefile
  head/x11-drivers/xf86-video-vesa/Makefile
  head/x11-drivers/xf86-video-vmware/Makefile
  head/x11-drivers/xf86-video-voodoo/Makefile
  head/x11-drivers/xorg-drivers/Makefile
  head/x11-drivers/xorgxrdp/Makefile
  head/x11-servers/xephyr/Makefile
  head/x11-servers/xorg-dmx/Makefile
  head/x11-servers/xorg-nestserver/Makefile
  head/x11-servers/xorg-nestserver/distinfo
  head/x11-servers/xorg-server/Makefile
  head/x11-servers/xorg-server/distinfo
  head/x11-servers/xorg-server/files/20-evdev-kbd.conf
  head/x11-servers/xorg-server/files/config_Makefile.am
  head/x11-servers/xorg-server/files/configure.ac
  head/x11-servers/xorg-server/files/hw_xfree86_Makefile.am
  head/x11-servers/xorg-server/files/patch-CVE-2017-10971
  head/x11-servers/xorg-server/files/patch-CVE-2017-10972
  head/x11-servers/xorg-server/files/patch-CVE-2017-12176
  head/x11-servers/xorg-server/files/patch-CVE-2017-12177
  head/x11-servers/xorg-server/files/patch-CVE-2017-12178
  head/x11-servers/xorg-server/files/patch-CVE-2017-12179
  head/x11-servers/xorg-server/files/patch-CVE-2017-12183
  head/x11-servers/xorg-server/files/patch-CVE-2017-1218x
  head/x11-servers/xorg-server/files/patch-CVE-2017-1218y
  head/x11-servers/xorg-server/files/patch-CVE-2017-13721
  head/x11-servers/xorg-server/files/patch-CVE-2017-13723
  head/x11-servers/xorg-server/files/patch-Xserver-hw-xfree86-os-support-misc-Makefile.in
  head/x11-servers/xorg-server/files/patch-config_Makefile.in
  head/x11-servers/xorg-server/files/patch-config_config-backends.h
  head/x11-servers/xorg-server/files/patch-config_config.c
  head/x11-servers/xorg-server/files/patch-config_devd.c
  head/x11-servers/xorg-server/files/patch-config_udev.c
  head/x11-servers/xorg-server/files/patch-configure
  head/x11-servers/xorg-server/files/patch-glamor_glamor__dash.c
  head/x11-servers/xorg-server/files/patch-hw_xfree86_Makefile.in
  head/x11-servers/xorg-server/files/patch-hw_xfree86_common_xf86AutoConfig.c
  head/x11-servers/xorg-server/files/patch-hw_xfree86_common_xf86Config.c
  head/x11-servers/xorg-server/files/patch-hw_xfree86_common_xf86Globals.c
  head/x11-servers/xorg-server/files/patch-hw_xfree86_common_xf86Xinput.c
  head/x11-servers/xorg-server/files/patch-hw_xfree86_dri2_pci__ids_i965__pci__ids.h
  head/x11-servers/xorg-server/files/patch-hw_xfree86_os-support_bsd_bsd__init.c
  head/x11-servers/xorg-server/files/patch-hw_xfree86_os-support_bsd_i386__video.c
  head/x11-servers/xorg-server/files/patch-hw_xfree86_xorg-wrapper.c
  head/x11-servers/xorg-server/files/patch-include_dix-config.h.in
  head/x11-servers/xorg-server/files/patch-os_io.c
  head/x11-servers/xorg-server/files/patch-test_xtest.c
  head/x11-servers/xorg-server/files/patch-xkb_Makefile.in
_U  head/x11-servers/xorg-server/files/pkg-deinstall.in
_U  head/x11-servers/xorg-server/files/pkg-install.in
  head/x11-servers/xorg-server/files/xkb_Makefile.am
  head/x11-servers/xorg-server/pkg-message
  head/x11-servers/xorg-server/pkg-plist
  head/x11-servers/xorg-vfbserver/Makefile
  head/x11-servers/xorg-vfbserver/distinfo
  head/x11-servers/xwayland/Makefile
  head/x11-servers/xwayland/distinfo
Comment 142 Niclas Zeising freebsd_committer 2020-02-20 21:22:28 UTC
This has been committed.  Leave the PR open for a while still, in case there is fallout.

I mangled the properties on
head/x11-servers/xorg-server/files/pkg-deinstall.in
head/x11-servers/xorg-server/files/pkg-install.in
This I've fixed already, but forgot to tag this PR.
Comment 143 commit-hook freebsd_committer 2020-02-20 21:38:20 UTC
A commit references this bug:

Author: zeising
Date: Thu Feb 20 21:37:47 UTC 2020
New revision: 526591
URL: https://svnweb.freebsd.org/changeset/ports/526591

Log:
  Add libtool dependency for all xorg servers

  Add libtool dependency for all xorg servers using USES=xorg-cat:xserver.
  This was missed in r526589.

  PR:		196678 (for tracking)

Changes:
  head/Mk/Uses/xorg-cat.mk
Comment 144 Jean-Sébastien Pédron freebsd_committer 2020-02-20 22:13:37 UTC
Congratulations for this commit! I've been using the patches posted here for years and it's been great :) I'm so happy this made it to the Ports tree!
Comment 145 Michael Gmelin freebsd_committer 2020-02-20 22:22:30 UTC
(In reply to Niclas Zeising from comment #142)

I can't believe all of this is finally coming together. Big thanks
to everyone who contributed!

Two questions:
- pkg-message mentions setting kern.evdev.rcpt_mask=6, I've been
  using kern.evdev.rcpt_mask=12 with this patch for years.
  Are there any practical advantages of using kbdmux (as
  suggested by these instructions)?
- Will we get an entry in UPDATING for users who didn't follow
  this development over the last couple of years?
Comment 146 commit-hook freebsd_committer 2020-02-20 22:27:30 UTC
A commit references this bug:

Author: zeising
Date: Thu Feb 20 22:26:53 UTC 2020
New revision: 526594
URL: https://svnweb.freebsd.org/changeset/ports/526594

Log:
  Add UPDATING entry for xorg-server

  Add UPDATING entry for xorg-server, detailing the change of device
  configuration backend.

  Reminded by:	linimon, grembo
  PR:		196678 (for tracking)

Changes:
  head/UPDATING
Comment 147 Niclas Zeising freebsd_committer 2020-02-20 22:31:56 UTC
(In reply to Michael Gmelin from comment #145)

I went with Wulf's recommendations in the pkg-message (actually, he wrote the original pkg-message).  There has been reports of issues when using rcpt_mask=12, at least in certain cases.  See comment #137 and comment #138 .
Comment 148 rozhuk.im 2020-02-20 22:36:33 UTC
udev vs devd - what pros/cons?
Comment 149 Oleh Hushchenkov 2020-02-21 06:49:49 UTC
Great, it finally happened. Thanks to everyone who made this possible!
Comment 150 Hans Petter Selasky freebsd_committer 2020-02-21 08:24:32 UTC
+1 :-)
Comment 151 Vladimir Kondratyev freebsd_committer 2020-02-22 18:53:57 UTC
it looks like FIXDRM issue is still here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244306
Comment 152 Lena 2020-02-24 19:17:16 UTC
(In reply to Niclas Zeising from comment #142)

> This has been committed.  Leave the PR open for a while still,
> in case there is fallout.

Upgrade to xorg-server-1.20 broke nvidia-driver-304.
Details:

Motherboard ASUS M2NPV-MX with integrated video GeForce 6150,
FreeBSD 11.3-RELEASE-p6 i386,
X installed entirely from packages (pkg.freebsd.org latest),
long old-style /etc/X11/xorg.conf : https://pastebin.com/uYBppQqP

I did `pkg upgrade` which upgraded these versions:

libinput-1.15.1             <  needs updating (port has 1.15.2)
nvidia-driver-304-304.137_5  <  needs updating (port has 304.137_6)
xf86-input-keyboard-1.9.0_3  <  needs updating (port has 1.9.0_4)
xf86-input-mouse-1.9.3_2    <  needs updating (port has 1.9.3_3)
xf86-video-scfb-0.0.5       <  needs updating (port has 0.0.5_2)
xf86-video-vesa-2.4.0_2     <  needs updating (port has 2.4.0_3)
xkbcomp-1.4.2               <  needs updating (port has 1.4.3)
xorg-drivers-7.7_5          <  needs updating (port has 7.7_6)
xorg-server-1.18.4_13,1     <  needs updating (port has 1.20.7,1)

Then after reboot `startx` failed:

================ WARNING WARNING WARNING WARNING ================
This server has a video driver ABI version of 24.1 that this
driver does not officially support.  Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
=================================================================
(WW) NVIDIA: The driver will continue to load, but may behave strangely.
(WW) NVIDIA: This driver was compiled against the X.Org server SDK from git commit d82c3cee02a99cf7861d1effaa5c7d38683a7783 and may not be compatible with the final version of this SDK.
/usr/local/lib/xorg/modules/drivers/nvidia_drv.so: Undefined symbol "xf86DisableRandR"
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
Comment 153 Niclas Zeising freebsd_committer 2020-02-24 19:28:23 UTC
(In reply to Lena from comment #152)

nVidia driver 304 does not support xorg-server 1.20, unfortunately.  Can you use a more recent version of the driver?
Comment 154 Jan Beich freebsd_committer 2020-02-24 19:31:35 UTC
Created attachment 211907 [details]
restore xf86DisableRandR

Lena, does the attached patch help?
Comment 155 Oleh Hushchenkov 2020-02-24 20:42:33 UTC
Maybe it's a good idea to create a new port for legacy xorg-server?
Comment 156 VVD 2020-02-24 20:46:40 UTC
(In reply to Jan Beich from comment #154)
> Created attachment 211907 [details]
> restore xf86DisableRandR
>
> Lena, does the attached patch help?

[   483.404] (II) Initializing extension GLX
[   483.404] (II) Indirect GLX disabled.(EE) Not enabling extension GLX: maximum number of events or errors exceeded.
[   483.404] (EE) Failed to initialize GLX extension
[   483.404] (II) Initializing extension NV-GLX
[   483.404] (II) Initializing extension NV-CONTROL
[   483.404] (II) Initializing extension XINERAMA
[   483.405] (EE) 
[   483.405] (EE) Backtrace:
[   483.418] (EE) 0: /usr/local/bin/Xorg (OsInit+0x37a) [0x41b3ca]
[   483.419] (EE) 1: /lib/libthr.so.3 (pthread_sigmask+0x53e) [0x800b1282e]
[   483.420] (EE) 2: /lib/libthr.so.3 (pthread_getspecific+0xdef) [0x800b1263f]
[   483.421] (EE) 3: ? (?+0x0) [0x7ffffffff193]
[   483.423] (EE) 4: /usr/local/bin/Xorg (RROutputChanged+0xa) [0x36ceba]
[   483.424] (EE) 5: ? (nvidiaAddDrawableHandler+0x71ef65) [0x806115a4a]
[   483.424] (EE) 
[   483.424] (EE) Segmentation fault at address 0x401960226
[   483.424] (EE) 
Fatal server error:
[   483.424] (EE) Caught signal 11 (Segmentation fault). Server aborting
[   483.424] (EE) 
[   483.424] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[   483.424] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[   483.424] (EE) 
[   483.711] (EE) Server terminated with error (1). Closing log file.

12.1 amd64.
Comment 157 Jens Grassel 2020-02-25 13:44:48 UTC
Hi,

I was hit with weird behaviour after the upgrade of xorg-server on several machines using nvidia graphics cards (Geforce GT 620 and 1030).

The machines either crashed X (black screen, no keyboard controls, but X still killable via ssh) or started up but no mouse worked and the keyboard produces weird character combinations on each keypress making it unuseable.

Downgrading the following packages fixed the problem for me:

xf86-input-keyboard (r516607)
xf86-input-libinput (r516607)
xf86-input-mouse    (r516607)
xorg-server         (r524048)

Running 12.1-RELEASE-p2 GENERIC amd64 and packages are installed via pkg only, except for the downgrade.

Maybe the cause is also the change from devd to udev in the package? Sadly I currently don't have much time to play around with it because the machines are in use.

Kind regards,

Jens
Comment 158 Michael Gmelin freebsd_committer 2020-02-25 14:18:08 UTC
(In reply to Jens Grassel from comment #157)

Once you have more time to test, please try running
https://github.com/grembo/xorg-udev-setup-check
on your machine.

You can fetch it directly:

fetch https://raw.githubusercontent.com/grembo/xorg-udev-setup-check/master/xorg-udev-setup-check.sh

In your case (nvidia), the procedure would be

- Run (as an unprivileged user):

  ./xorg-udev-setup-check.sh -d


  ("-d" skips DRM checks) 
- Correct all errors it reports, consider its recommendations.

If it still doesn't work afterwards, please run

  ./xorg-udev-setup-check.sh -des

  ("-e" collects evidence, "-s" uses sudo to run
  libinput list-devices - not necessary if you
  run it as root)

to collect (hopefully) all relevant information on your
setup and share it here. In case your machine still hangs,
but X is running, please ssh into the machine, set DISPLAY
and run the script from there, e.g.:

  DISPLAY=:0 ./xorg-udev-setup-check.sh -des
Comment 159 Lena 2020-02-25 15:47:46 UTC
(In reply to Jan Beich from comment #154)

> Created attachment 211907 [details]
> restore xf86DisableRandR
> Lena, does the attached patch help?

Different error:

================ WARNING WARNING WARNING WARNING ================
This server has a video driver ABI version of 24.1 that this
driver does not officially support.  Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
=================================================================
(WW) NVIDIA: The driver will continue to load, but may behave strangely.
(WW) NVIDIA: This driver was compiled against the X.Org server SDK from git commit d82c3cee02a99cf7861d1effaa5c7d38683a7783 and may not be compatible with the final version of this SDK.
(EE)
(EE) Backtrace:
(EE) 0: /usr/local/bin/Xorg (OsInit+0x396) [0x81ec23c]
(EE) 1: /lib/libthr.so.3 (_pthread_sigmask+0x60b) [0x285f35bb]
(EE) 2: /lib/libthr.so.3 (_pthread_getspecific+0xef2) [0x285f3322]
(EE) 3: ? (?+0x0) [0xbfbff004]
(EE) 4: ? (nvidiaAddDrawableHandler+0x7c4e83) [0x2c823a56]
(EE) 5: ? (?+0x0) [0x1]
(EE) unw_step failed: unspecified (general) error [-1]
(EE)
(EE) Segmentation fault at address 0xd4011e

FreeBSD 11.3-RELEASE-p6 i386

(In reply to Niclas Zeising from comment #153)

> nVidia driver 304 does not support xorg-server 1.20, unfortunately.
> Can you use a more recent version of the driver?

I tried, error messages:

nvidia-driver-440.59 is only for amd64, while you are running i386.

NVRM: The NVIDIA GeForce 6150 GPU installed in this system is
NVRM:  supported through the NVIDIA 304.xx Legacy drivers. Please
NVRM:  visit http://www.nvidia.com/object/unix.html for more
NVRM:  information.  The 340.108 NVIDIA driver will ignore
NVRM:  this GPU.  Continuing probe...
Comment 160 Jens Grassel 2020-02-25 17:45:34 UTC
(In reply to Michael Gmelin from comment #158)

Hi,

I've run the script on one of the machines and applied the suggested things until it finished saying it should be okay now but to no avail.

In the end I had to downgrade the packages again to have a working X. :-(

As a side note: I applied the script on a laptop with Intel chipset graphics which ran totally fine with the updated xorg server. But after I applied the hints suggested from the script the touchpad stopped working. ;-)

Kind regards,

Jens
Comment 161 Michael Gmelin freebsd_committer 2020-02-25 19:07:44 UTC
(In reply to Jens Grassel from comment #160)

Did you run the evidence collection and can share that?

>  If it still doesn't work afterwards, please run
>  
>  ./xorg-udev-setup-check.sh -des
>  
>  ("-e" collects evidence, "-s" uses sudo to run
>  libinput list-devices - not necessary if you
>  run it as root)
>  
>  to collect (hopefully) all relevant information on your
>  setup and share it here. In case your machine still hangs,
>  but X is running, please ssh into the machine, set DISPLAY
>  and run the script from there, e.g.:

This would help to understand your setup and what's going on.
Comment 162 rozhuk.im 2020-02-25 21:59:08 UTC
(In reply to Jens Grassel from comment #157)

This is your local issue.
I have systems with gt610, gt730, gt1030 - all works fine!
I update packages from source, rebuild kernel and drivers, nvidia driver too.

Try to not use packages and rebuild at least nvidia driver and other xorg drivers.
Comment 163 rozhuk.im 2020-02-25 22:00:54 UTC
All my systems run with nvidia-driver-390-390.132
Comment 164 Jens Grassel 2020-02-26 16:51:07 UTC
Seems I could narrow it down somewhat.

Here is the output from the script:

```
Info: kern.evdev.rcpt_mask is set to 6.     
You might consider setting it to 12 in case of problems
(which will change keyboard events to go to hardware)
                                                         
Info: Synaptics support isn't enabled.
This is only relevant if you use a synapctics touchpad.
You can enable synaptics support using these commands:
                                                                                                                   
echo hw.psm.synaptics_support=1 >>/boot/loader.conf
reboot                 

Info: Trackpoint support isn't enabled.
This is only relevant if you use a trackpoint, like the
ones found in Lenovo laptops. Needs to be enabled
to support features like middle mouse button support
(e.g. to paste or to support middle-click+trackpoint
to scroll).

You can enable trackpoint support using these commands:

echo hw.psm.trackpoint_support=1 >>/boot/loader.conf
reboot

Info: Found custom configuration files
The following custom configuration file(s) exist,
please make sure their contents are sane:

/usr/local/etc/X11/xorg.conf.d/fonts.conf
/usr/local/etc/X11/xorg.conf.d/keyboard.conf
/usr/local/etc/X11/xorg.conf.d/nvidia.conf

You can disable this check by running

./xorg-udev-setup-check.sh -f -d

>> To suppress info messages, run ./xorg-udev-setup-check.sh -i -d

Done: All checks passed
```

The source of trouble seems to be the keyboard.conf file. The mouse seems to work after I removed my custom mouse.conf file.
However the following keyboard.conf caused weird characters to appear on every keypress and make X unuseable:

```
Section "InputClass"
        Identifier              "Keyboard Defaults"
        Driver                  "kbd"
        MatchIsKeyboard         "on"
        Option                  "XkbModel"   "microsoft4000"
        Option                  "XkbLayout"  "de"
        Option                  "XkbVariant" "nodeadkeys"
EndSection
```

It works if I remove the "Driver" line but then all options like layout and variant are ignored. :-(

So, how do I set keyboard layout and variant now without breaking X?

Kind regards,

Jens
Comment 165 Jens Grassel 2020-02-27 09:32:56 UTC
Thanks to an email from Michael I got it working (somehow).

The solution was indeed removing the custom keyboard configuration and set the keyboard layout and other stuff via something like `setxkbmap -model microsoft4000 -layout de -variant nodeadkeys` in the `~/.xinitrc` file.

However for the machines that are used by multiple users (login manager is slim) this doesn't work because slim starts up with the default (us) keyboard which is pretty annoying regaring entering passwords. So I guess I'll go hunting for another login manager which allows changing the keyobard layout.

Many thanks for your help. I'd suggest that maybe something regarding this should be added to the pkg-message (not only the kern.evdev.rcpt_mask notice).

Kind regards,

Jens
Comment 166 x11max1@unitybox.de 2020-02-27 12:19:45 UTC
(In reply to Jens Grassel from comment #165)

I changed the following things to make xorg-server-1.20.7,1 running including attached devices like keyboard, wacom and so on.

/boot/device.hints
# keyboard problem updating xorg-server xorg-server: 1.18.4_12,1 -> 1.20.7,1
hint.kbdmux.0.disabled="1"

/etc/sysctl.conf
# fuer evdev devices ; pads , keyboard, etc
kern.evdev.rcpt_mask=12
sysctl kern.geom.debugflags=16

# added new conf file regarding devices
/usr/local/etc/X11/xorg.conf.d/99-evdev-new.conf
Section "InputClass"
    Identifier "libinput keyboard catchall"
    MatchIsKeyboard "on"
    MatchDevicePath "/dev/input/event*"
    Driver "libinput"
    Option "XkbRules" "evdev"
EndSection

Section "InputClass"
    Identifier "libinput touchpad catchall"
    MatchIsTouchpad "on"
    MatchDevicePath "/dev/input/event*"
    Driver "libinput"
    Option "MiddleEmulation" "on"
    Option "DisableWhileTyping" "off"
EndSection

    Identifier "libinput keyboard catchall"
    MatchIsKeyboard "on"
    MatchDevicePath "/dev/input/event*"
    Driver "libinput"
    Option "XkbRules" "evdev"
EndSection

Section "InputClass"
    Identifier "libinput touchpad catchall"
    MatchIsTouchpad "on"
    MatchDevicePath "/dev/input/event*"
    Driver "libinput"
    Option "MiddleEmulation" "on"
    Option "DisableWhileTyping" "off"
EndSection

~/.xinitrc
# SLIM Session Manager
#
#setxkbmap de
# setxkbmap de -variant nodeadkeys -model pc105
setxkbmap -v -layout de -model macintosh
xset fp+ /usr/local/share/fonts/urwfonts
xset fp rehash
xset fp+ /usr/local/share/fonts/TrueType
xset fp rehash
Comment 167 commit-hook freebsd_committer 2020-03-08 19:27:43 UTC
A commit references this bug:

Author: zeising
Date: Sun Mar  8 19:27:27 UTC 2020
New revision: 528071
URL: https://svnweb.freebsd.org/changeset/ports/528071

Log:
  graphics/mesa-libs: Change default to use DRI3

  Change the default mesa configuration to use DRI3 rather than the older DRI2
  interface.  This should improve performance somewhat, and alleviates the need
  for the FIXDRM option in x11-servers/xorg-server.

  Remove the FIXDRM option from x11-servers/xorg-server.

  Add an UPDATING entry for the change.

  For users of graphics/drm-legacy-kmod or the base graphics drivers, this might
  cause regressions.  If you experience problems when running OpenGL applications
  please force the use of the DRI2 backend by setting the LIBGL_DRI3_DISABLE
  environment variable to 1 before starting any OpenGL application.  This is
  easiest done by adding it to your shell startup file or .xinitrc.

  Add UPDATING entry for xorg-server, detailing the change of device
  configuration backend.

  PR:		196678, 244306 (for tracking)

Changes:
  head/UPDATING
  head/graphics/mesa-dri/files/patch-src_egl_drivers_dri2_platform__x11.c
  head/graphics/mesa-dri/files/patch-src_glx_glxext.c
  head/graphics/mesa-libs/Makefile
  head/x11-servers/xorg-server/Makefile
Comment 168 Niclas Zeising freebsd_committer 2020-03-08 19:41:21 UTC
We are getting closer!

The need for FIXDRM should be gone.  If you used that option before, please try without it, after updating mesa-libs to 18.3.2_4 or later versions.
If you still have trouble even after this update, let me know asap in pr 244306 .

There are still some regressions with keyboard layouts and keys breaking, as well as mice.  If you have trouble with either of these, please try the patch in https://reviews.freebsd.org/D23860 and report back.

Thank you!

Regards
Niclas Zeising
FreeBSD Graphics Team
Comment 169 Chris Hutchinson 2020-04-04 01:59:18 UTC
I'm stuck on 3.04. I use it to build ports I
Maintain. So need nothing fancy. BUT, with the
advent of new Xorg. I am no longer able to use
x11;
================ WARNING WARNING WARNING WARNING ================
This server has a video driver ABI version of 24.1 that this
driver does not officially support.  Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
=================================================================
(WW) NVIDIA: The driver will continue to load, but may behave strangely.
(WW) NVIDIA: This driver was compiled against the X.Org server SDK from git comm
it d82c3cee02a99cf7861d1effaa5c7d38683a7783 and may not be compatible with the f
inal version of this SDK.
ld-elf.so.1: /usr/local/lib/xorg/modules/drivers/nvidia_drv.so: Undefined symbol
 "xf86DisableRandR"

I've followed every bit of advice, or suggestion I can find on the
interweb. But to no avail.

Am I no longer able to use X?

Thanks

--Chris
Comment 170 Chris Hutchinson 2020-04-04 02:02:28 UTC
Sorry. Forgot to mention:
Fresh install of 13/current from 2 weeks ago.
ports from head yesterday.
Comment 171 Chris Hutchinson 2020-04-04 08:24:24 UTC
I was able to get Xorg to start using by xf86-video-nv.
With xf86-input-evdev keyboard almost works. But
up arrow does not. Mouse will only work with legacy
entry X11/xorg.conf.d/
Performance and looks are not as good as previous Xorg.
My current experience suggests this was a step
backwards. The previous version was much easier to
setup, and all the drivers just worked.

Am I missing something?
Comment 172 Ivan 2020-04-04 08:29:45 UTC
304 doesn't support xorg 1.20
Comment 173 Niclas Zeising freebsd_committer 2020-04-04 10:28:40 UTC
(In reply to Chris Hutchinson from comment #171)

Hi!
As others have already told you, nVidia driver version 304 is not supported by xserver 1.20.  Since this is a binary driver, unfortunately you have to talk to nVidia about this, and see if they can make the driver support xserver 1.20

As for the other issues, I suggest that you try using xf86-input-libinput instead of xf86-input-evdev.  xf86-input-libinput should have been installed if you use the standard configuration, but if you have adjusted xorg-drivers, or is not installing xorg-drivers at all, this might not be the case.

I also suggest that you try without any xorg configuration at all, it should not be needed.  Regarding the keyboard, please provide the output of setxkbmap -query.  For the mice, please try to set the sysctl kern.evdev.rcpt_mask=12, and if you are using a laptop with a touchpad, try setting hw.psm.synaptics_support=1 and hw.psm.trackpoint=1 in /boot/loader.conf and restart the system.
Comment 174 Michael Gmelin freebsd_committer 2020-04-04 13:00:03 UTC
(In reply to Chris Hutchinson from comment #171)

Move /etc/X11/xorg.conf out of the way in case you have any.

For your mouse: Try setting sysctl kern.evdev.rcpt_mask=12
For your keyboard: Add
setxkbmap -model pc105 -layout de

to your ~/.xinitrc .

(change layout to whatever is required in your country, e.g. US
would be setxkbmap -model pc104 -layout us - at least I think so).

If you're on a laptop with (U)EFI, try using xf86-video-scfb instead of
the nvidia driver (I used this on an old MacBook successfully):

pkg install xf86-video-scfb
cat >/usr/local/etc/X11/xorg.conf.d/driver-scfb.conf<<EOF
Section "Device"
    Identifier     "Device0"
    Driver         "scfb"
    Option         "NoAccel" "On"
EndSection
EOF

Once you tested all of these, you can debug our configuration
using a script I wrote (https://github.com/grembo/xorg-udev-setup-check).
Note that you shouldn't follow it blindly, but it can be helpful.

You can fetch it directly:

fetch https://raw.githubusercontent.com/grembo/xorg-udev-setup-check/master/xorg-udev-setup-check.sh

In your case (nvidia), the procedure would be

- Run (as an unprivileged user):

  ./xorg-udev-setup-check.sh -d


  ("-d" skips DRM checks) 
- Correct all errors it reports, consider its recommendations.

If it still doesn't work afterwards, please run

  ./xorg-udev-setup-check.sh -des

  ("-e" collects evidence, "-s" uses sudo to run
  libinput list-devices - not necessary if you
  run it as root)

to collect (hopefully) all relevant information on your
setup and share it here. In case your machine still hangs,
but X is running, please ssh into the machine, set DISPLAY
and run the script from there, e.g.:

  DISPLAY=:0 ./xorg-udev-setup-check.sh -des
Comment 175 Chris Hutchinson 2020-04-04 19:14:39 UTC
(In reply to Niclas Zeising from comment #173)
Thank you for your reply, Niclas.
> As others have already told you, nVidia driver version
> 304 is not supported by xserver 1.20.

Yes. But there was evidence in comment #154 (a patch by Jan)
to Lena that work was being done.
> As for the other issues, I suggest that you try using
> xf86-input-libinput instead of xf86-input-evdev.

I installed xf86-input-libinput immediately after installing
xorg-server. As the pkg-message told me to do so. I also
added kern.evdev.rcpt_mask=6 to sysctl.conf(8). I also attempted
kern.evdev.rcpt_mask=12. Neither appearaed to have any effect.
> I also suggest that you try without any xorg configuration at all.

When I initiated the first test to see if it would work. There
was nothing in X11/xorg.conf.d/. I initiated Xorg -retro. I was
given a screen, and the mouse functioned. So I restarted X with
a DE designated in ~/.initrc. Where I found everything *almost*
worked. But the up arrow key didn't function. So no history recall
in my shell, and nearly impossible to edit files. It was then
that I began to experiment, in an effort to obtain a working
up arrow key, by adding/tweaking conf file(s). Borrowing from
examples in this thread. At this point, if starting moused, and
adding a simple mouse conf file, I have a mouse. This is
currently the only file I have in X11/xorg.conf.d/

setxkbmap -query:
rules:  evev
model:  pc105
layout:  us

DETAILS:
FreeBSD 13.0-CURRENT r358902
ports are from HEAD at 2 days ago
NVIDIA GeForce 6150SE at 00@00:13:0
xf86-video-nv
mouse/keyboard are PS2

Thank you again, for taking the time to respond, Niclas.

--Chris
Comment 176 Chris Hutchinson 2020-04-04 19:41:34 UTC
(In reply to Michael Gmelin from comment #174)
Thank you for your reply, Michael.

I currently have nothing but a simple mouse conf file in
X11/xorg.conf.d/. I can remove it, as it appears that I
actually obtain the mouse by starting moused.

With all conf files removed from X11/xorg.conf.d/

> setxkbmap -model pc105 -layout de

eureka!

# cat ~/.xinitrc
setxkbmap -model pc105 -layout us
startxfce4

I now have a working up arrow. You're brilliant, Michael!
Thank you!

OTOH I'm still only able to obtain a mouse by the use of
moused. I'm not too concerned about this. But as I
understand it. I should already have this, by virtue of
adding (u|e)vdev_enable="YES" to rc.conf(5). Correct?

BTW I had already used your script when I first encountered
problems. I forgot to mention it here, as I had already
mentioned it in a thread I started on the x11 | current
mailing lists. It gave me a "clean bill of health". Thanks!

Any further suggestions?

Thanks again.

--Chris
Comment 177 Niclas Zeising freebsd_committer 2020-04-04 20:09:57 UTC
(In reply to Chris Hutchinson from comment #176)
Can you check, out of curiosity, which version of libxkbcommon you have installed?

There is no such thing as evdev_enable=YES or similar for rc.conf, but if you have a custom kernel config, ensure that you have the following in it:
# evdev interface
options         EVDEV_SUPPORT           # evdev support in legacy drivers
device          evdev                   # input event device support
device          uinput                  # install /dev/uinput cdev
as otherwise the prerequisite evdev kernel support isn't there.
Comment 178 Michael Gmelin freebsd_committer 2020-04-04 21:31:29 UTC
(In reply to Chris Hutchinson from comment #176)

Good to hear your keyboard is working now.
What kind of mouse device are you using (USB mouse, touchpad,
if so, which model etc.)?

It would be great if you could collect some debug output and share
it with me/us (direct email grembo@freebsd.org).

Command:

./xorg-udev-setup-check.sh -desk

("s" requires sudo, otherwise run it as root without "s").

It won't send anything on its own, so you need to
email the output file (it shows you instructions).

This allows you to check if you're okay with its content
(it shouldn't contain anything sensitive, but better
safe than sorry).
Comment 179 Chris Hutchinson 2020-04-04 22:12:31 UTC
(In reply to Niclas Zeising from comment #177)
> There is no such thing as evdev_enable=YES
Right. I performed some further investigation after my
post here, and discovered I had udev only (for rc.conf).

> but if you have a custom kernel config...
I'm on GENERIC as supplied from official install media.
As I understand it. (recent) GENERIC comes with evdev
support in it. I'm on a 2 week old 13/current. So I think
I must have it already. Yes?

For the record. For the last decade I've built all of
my deployments on a dedicated builder for all my rollouts.
So I'm never subjected to any irregularities.

This was essentially my first install from official
media in ten years. It was an effort to evaluate
usability from a first time users standpoint. In all
fairness, 13/current is not the best candidate for
this. But I also needed a 13/current to test ports I
maintain on. So this was my first choice for the
evaluation.

Thanks for the reply, Niclas. :)

--Chris
Comment 180 Chris Hutchinson 2020-04-04 23:46:27 UTC
For completeness.

On the following hardware:
FreeBSD 13.0-CURRENT r358902
ports are from HEAD at 2 days ago
NVIDIA GeForce 6150SE at 00@00:13:0
xf86-video-nv
mouse/keyboard are PS2

I was finally able to get a usable DE
by performing the following:

add:
setxkbmap -model pc105 -layout us
to ~/.xinitrc

Then performing:
# sysctl kern.evdev.rcpt_mask=12
kern.evdev.rcpt_mask 3 -> 12

This last one provided a mouse for me.
The one above that, provided keyboard.
Of possible interest; attempting to
change kern.evdev.rcpt_mask previously
made no apparent difference. Conclusion;
It may be necessary to perform it more
than once, maybe bouncing the box between
attempts.

In any event. The settings, and actions above
provided a working X && DE on the hardware, and
OS version listed above. I hope that this
information will prove helpful to others.

Lastly, a *huge* thanks to Niclas, and Michael
for taking the time to so quickly respond to my
problem(s)!

--Chris
Comment 181 shadow53+freebsd 2020-04-07 09:13:00 UTC
I'm not sure whether this bug is the best place to put this, but it seems related enough. If it should go elsewhere, let me know.

I'm trying to use my Logitech F310 with the updated xorg-server, libinput, and SDL2 on 12.1-RELEASE-p3. SDL2 does not recognize the device as a joystick/gamepad, and a little bit of digging makes me think xorg is having some related issues.

The F310 has a switch that allows you to toggle between XInput and Direct Input modes. XInput just is not recognized:

/var/log/Xorg.0.log
-------------------
[   104.266] (II) config/udev: Adding input device Logitech Gamepad F310 (/dev/i
nput/event3)
[   104.266] (II) No input driver specified, ignoring this device.
[   104.266] (II) This device may have been added with another device file.

Direct input is recognized as a pointer device and the left thumbstick can be used to move the mouse pointer on screen, but nothing else works. Running 'libinput debug-events' shows that it does not recognize the d-pad at all, but the other buttons cause an error like the following on every button press and release:

libinput bug: timer event3 debounce: offset more than 5s, now 2299831 expire 1404381708

I should note that I am running webcamd and it is able to attach to the F310 in XInput mode, but it doesn't seem to help anything. I'm also using custom packages built using Poudriere, so here are the port options for the relevant packages I can think of:

devel/sdl2
----------
OPTIONS_FILE_UNSET+=ALSA
OPTIONS_FILE_SET+=ASM
OPTIONS_FILE_SET+=DLOPEN
OPTIONS_FILE_SET+=HIDAPI
OPTIONS_FILE_UNSET+=JACK
OPTIONS_FILE_UNSET+=NAS
OPTIONS_FILE_SET+=OSS
OPTIONS_FILE_SET+=PTHREADS
OPTIONS_FILE_SET+=PULSEAUDIO
OPTIONS_FILE_UNSET+=SAMPLERATE
OPTIONS_FILE_SET+=SDL_ATOMIC
OPTIONS_FILE_SET+=SDL_AUDIO
OPTIONS_FILE_SET+=SDL_CPUINFO
OPTIONS_FILE_SET+=SDL_EVENTS
OPTIONS_FILE_SET+=SDL_FILE
OPTIONS_FILE_SET+=SDL_HAPTIC
OPTIONS_FILE_SET+=SDL_JOYSTICK
OPTIONS_FILE_SET+=SDL_LOADSO
OPTIONS_FILE_SET+=SDL_POWER
OPTIONS_FILE_SET+=SDL_RENDER
OPTIONS_FILE_SET+=SDL_THREADS
OPTIONS_FILE_SET+=SDL_TIMERS
OPTIONS_FILE_SET+=SDL_VIDEO
OPTIONS_FILE_UNSET+=SNDIO
OPTIONS_FILE_SET+=UDEV
OPTIONS_FILE_SET+=VIDEO_KMSDRM
OPTIONS_FILE_SET+=VIDEO_OPENGL
OPTIONS_FILE_SET+=VIDEO_OPENGLES2
OPTIONS_FILE_SET+=VIDEO_WAYLAND
OPTIONS_FILE_SET+=VIDEO_X11

multimedia/webcamd
------------------
OPTIONS_FILE_SET+=COMPAT32
OPTIONS_FILE_UNSET+=DEBUG
OPTIONS_FILE_SET+=DVB
OPTIONS_FILE_SET+=HAL
OPTIONS_FILE_SET+=INPUT
OPTIONS_FILE_SET+=KEYBOARD
OPTIONS_FILE_SET+=MOUSE
OPTIONS_FILE_SET+=RADIO
OPTIONS_FILE_UNSET+=VT_CLIENT
OPTIONS_FILE_UNSET+=VT_SERVER
OPTIONS_FILE_SET+=WEBCAM

sysutils/uhidd
--------------
OPTIONS_FILE_SET+=DEVD

x11-servers/xorg-server
-----------------------
OPTIONS_FILE_SET+=FIXDRM
OPTIONS_FILE_SET+=SUID
OPTIONS_FILE_UNSET+=DEVD
OPTIONS_FILE_SET+=UDEV


I do not have an options file for x11-drivers/xf86-input-libinput, so I assume that means it is using default options?

I also even tried the patch for SDL2 at https://forums.freebsd.org/threads/joystick-api.72643/#post-456120 but that didn't work.

As I mentioned above, I'm putting this here because I *think* it is related to Xorg's use of udev/evdev, but I'm really not familiar enough with the technologies to be sure. I can post this as a separate bug if needed. Either way, I can help debug the above libinput error and test any potential solutions.
Comment 182 rozhuk.im 2020-04-07 12:58:18 UTC
(In reply to shadow53+freebsd from comment #181)

Logitech F310 should work, it is not xorg related.
I use F310, F710 without any settings in xorg, all apps work with game pad via /dev/input/js*.

In past I fix game pad support in SDL (not SDL2): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231370 - for DInput mode, as I remember. And in this mode SDL open usb device without any drivers and without webcamd.

You can install sysutils/jstest-gtk to ensure that your game pad work ok.
I check now F310 works in both modes in this app, via webcamd.


PS: I do not try to use game pad to work with xorg apps as mouse, all apps that I use with game pad have game pad support in their code.
Comment 183 Greg V 2020-04-08 15:30:16 UTC
(In reply to shadow53+freebsd from comment #181)

SDL2 on FreeBSD currently uses USB devices directly (IIRC via libusb), so make sure you have permissions on the corresponding ugen / dev/usb devices. Nothing xorg/evdev related affects SDL2 installed from ports.

I've tried to make it use evdev (https://github.com/myfreeweb/freebsd-ports-dank/commit/fb963ddfef01a01d42de07a4a87186be2a9bd6a9) but it did not work yet.

btw, speaking of "XInput" in evdev, you can use a native kernel driver now instead of webcamd :) https://github.com/wulf7/iichid

> Running 'libinput debug-events' shows that it does not recognize the d-pad at all

This is correct.
Comment 184 rozhuk.im 2020-04-08 20:36:27 UTC
(In reply to Greg V from comment #183)

https://github.com/wulf7/iichid
it is "must have" driver for wife's notebook, but then it came to base probably some updates will be required for webcamd devd config - to not handle already handled by iichid devices.
Comment 185 Greg Fitzgerald 2020-04-13 01:30:30 UTC
Not sure if this is related or not. I have a ducky shrine 7 keyboard that has 4 Multimedia keys. They always worked with the following in my rc.conf

uhidd_flags="-kmohsu"
uhidd_enable="YES"

Now none of the keys register. I tried to install iichid thinking that might be the new way, i'm a little confused on all this. That didn't help either. Not sure if I should be reporting this here or not. Sorry for the noise in advance if I'm in the wrong place.

dmesg:

ugen2.2: <DuckyChannel International Co., Ltd. Ducky Keyboard> at usbus2
ukbd0: <DuckyChannel International Co., Ltd. Ducky Keyboard, class 0/0, rev 2.00/1.10, addr 2> on usbus2
uhid1: <DuckyChannel International Co., Ltd. Ducky Keyboard, class 0/0, rev 2.00/1.10, addr 2> on usbus2

usbconfig:

ugen2.2: <DuckyChannel International Co., Ltd. Ducky Keyboard> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
Comment 186 Michael Gmelin freebsd_committer 2020-04-13 13:06:12 UTC
(In reply to Greg Fitzgerald from comment #185)

> Not sure if this is related or not. I have a ducky shrine 7 keyboard that has 4 > Multimedia keys. They always worked with the following in my rc.conf
>
> uhidd_flags="-kmohsu"
> uhidd_enable="YES"

Hi Greg,

sysutild/uhidd won't work anymore, but you can use usbhidaction from base.

Please see here for an example how to use it:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244339#c6

(note that the patch required to make multimedia work in there might not be needed in your case)
Comment 187 Vladimir Kondratyev freebsd_committer 2020-04-14 00:30:03 UTC
(In reply to Greg Fitzgerald from comment #185)

> Now none of the keys register.
You can always try to rebuild kernel with option EVDEV_SUPPORT disabled. It should trigger old-style behavior of auto-configuration backends. Or manually attach xf86-input-keyboard driver to kbdmux in xorg.conf.

Michael's advice with uhid is worth a try also.

> I tried to install iichid thinking that might be the new way,
> i'm a little confused on all this. That didn't help either.
This thread is a wrong place to report iichid issues. Welcome to project page: https://github.com/wulf7/iichid/issues
Comment 188 Niclas Zeising freebsd_committer 2020-04-15 19:58:25 UTC
I believe all outstanding issues with the update of xorg-server to 1.20.7 (and subsequently to 1.20.8) have been worked out.
If this is not the case, please let me know asap.  I'll close this PR in a couple of days.
Comment 189 Lena 2020-04-16 04:46:00 UTC
> I believe all outstanding issues with the update of xorg-server to 1.20.7 (and subsequently to 1.20.8) have been worked out.

What do you propose for Nvidia chips supported only by 304 driver?
Comment 190 Alex S 2020-04-16 07:20:58 UTC
(In reply to Lena from comment #189)

xf86-video-nv, xf86-video-vesa or just throw it away.
Comment 191 Lena 2020-04-16 07:46:47 UTC
(In reply to Alex S from comment #190)

> or just throw it away.

My video is integrated, fanless (silent). May be you are willing to throw away your motherboard and as a consequence buy also new processor and RAM, but I am not.
Comment 192 Gleb Popov freebsd_committer 2020-04-16 07:53:23 UTC
(In reply to Lena from comment #191)
It is not FreeBSD's fault that NVidia doesn't support 304 driver. You can try bugging them on their forum: https://forums.developer.nvidia.com/c/gpu-unix-graphics/freebsd-solaris/147
Comment 193 Alex S 2020-04-16 08:05:48 UTC
(In reply to Lena from comment #191)

Last time I checked, I enumerated 3 options.

> My video is integrated, fanless (silent).
> May be you are willing to throw away your motherboard
> and as a consequence buy also new processor and RAM, but I am not.

No PCI-e slots even? That basically makes you a vintage computing enthusiast.
Comment 194 Chris Hutchinson 2020-04-16 08:15:08 UTC
(In reply to Alex S from comment #193)
That comment was uncalled for, :(
Comment 195 Niclas Zeising freebsd_committer 2020-04-16 17:53:37 UTC
As others already pointed out, nVidia driver version 304 does not work with xorg-server 1.20, and there is nothing we can to about it.  This is a binary driver provided by nVidia and we have no way of changing it.  The only options is to talk to nVidia about updating version 304 so that it supports xserver 1.20, replace the graphics card, or use any of the options provided (xf86-video-scfb, xf86-video-vesa, xf86-video-nv) that are open source, but might not provide graphics acceleration.
Comment 196 Niclas Zeising freebsd_committer 2020-04-20 18:52:21 UTC
Closing this, all known issues have been worked out, except nVidia 304 which does not work with xserver 1.20

If you have issues, please reopen this PR, or open a new one.
Comment 197 Niclas Zeising freebsd_committer 2020-04-20 18:52:39 UTC
Closing this, all known issues have been worked out, except nVidia 304 which does not work with xserver 1.20

If you have issues, please reopen this PR, or open a new one.