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
Hi, can you redo the patch as a diff against the current xorg-server port, so we can see the diff you made? Thanks.
Created attachment 151549 [details] updates to devd backend in diff form.
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)?
Hi, See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196978 --HPS
Yes, we can make the WEBCAMD IOCTL standard and work for those devices aswell if requested. --HPS
> 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.
File a PR for this and assign it to me. --HPS
BTW: Is there any news about getting this PR submitted to ports? --HPS
Created attachment 160696 [details] Devd patch for Xorg server
Created attachment 160697 [details] Devd file for Xorg server
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.
Created attachment 161034 [details] Devd patch for Xorg server
Created attachment 161035 [details] Devd file for Xorg server
Hi Jan, Can you re-test using the updated, attached patches? --HPS
(In reply to Jan Beich from comment #11) Looks like there was a missing OR of the device attributes into "attrs".
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.
Do you have a better suggestion?
Maybe we could do an IOCTL to figure out more specific information ...
Is this something which can be solved as a separate bug item?
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
(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
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
(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.
Rozhuk: Do you know if anyone is activly working on bringing these patches in?
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
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.
Created attachment 167354 [details] Xorg.0.log entries of wacom device
Which of the devd patches did you use? You should use the latest one from rozhuk.im@gmail.com in the attachments section. --HPS
(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
(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
(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.
(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.
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.
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/
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.
(In reply to Pierre Guinoiseau from comment #35) If you mean /dev/input/mice* - yes, try.
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
You need to install webcamd first or the v4l_compat port.
(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.
(In reply to Arto Pekkanen from comment #39) I will fix it and update patch in next 5-6 hours.
Created attachment 167594 [details] makes devd to hanle all known input devices and unknown in /dev/input/ linux/input.h now not required.
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?
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.
(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
(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.
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.
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.
Created attachment 179892 [details] devd: support webcamd, evdev, uhid, all from /dev/input Update to build with Xorg 1.18.4
Can someone please commit this?
(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.
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
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
(In reply to Vladimir Kondratyev from comment #50) devd code is a very small part of patch.
(In reply to Andriy Gapon from comment #51) On my systems - OK. Try reinstall autotools.
(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?
(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.
(In reply to rozhuk.im from comment #54) You probably didn't notice "poudriere" in my comment.
(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.
(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.
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.
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?
(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
(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
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?
(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.
(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
(In reply to Vladimir Kondratyev from comment #66) > 2. Webcamd does not know nothing about ENODEV 2. Webcamd knows nothing about ENODEV Fixed
(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.
(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?
(In reply to Matthew Rezny from comment #69) Ask Jan Beich, why "priv->isParent" check added.
(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"
(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.
Created attachment 180880 [details] update Xorg to 1.19.3 and integrate collective devd enhancements
(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
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.
Hi! Since the patch includes updates to xserver, and a quite major one at that, it will take some time to digest it all.
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.
For anyone interested in testing this patch in VirtualBox, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227238
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
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?
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.
(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.
(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?
(In reply to Jean-Sébastien Pédron from comment #83) > Could you please point us to those patches? https://reviews.freebsd.org/D15070
> 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
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?
(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.
(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.
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?
(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.
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.
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.
Created attachment 196037 [details] update Xorg to 1.19.6 and integrate collective devd enhancements Fix tigervnc build with Xorg 1.19
How is this going? It's a 3 years old "bug" and we should update to 1.20 someday too, right?
(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.
It would be great if this will be committed.
(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?
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.
There's this one-liner security issue: https://twitter.com/hackerfantastic/status/1055517801224396800 Did anyone check the current port or this update ?
(In reply to Kurt Jaeger from comment #99) The version currently in FreeBSD ports is not vulnerable.
Created attachment 198703 [details] update Xorg to 1.20.3 and integrate collective devd enhancements Handle CVE-2018-14665
Looks like dependency is reversed?
I don't think this blocks 233044. Closed.
Hi! I'd like to wait with this until pr222905, which is in progress, is committed.
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.
(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.
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 :)
(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 :)
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
See work in progress and testing at https://github.com/FreeBSDDesktop/freebsd-ports/tree/feature/xserver-1.20
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.
I have Xorg 1.19.6 patch though, maybe it was fixed with recent one?
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.
There are some sysctls you need to configure aswell, and you need the input-evdev for x86 installed. Can you check? --HPS
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.
(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
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.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241650 x11-drivers/xf86-video-scfb: remove LoaderGetOS()
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
(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
(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
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
(In reply to Vladimir Kondratyev from comment #122) Thanks for the new patch! I'll incorporate it into our dev tree asap.
See: https://github.com/FreeBSDDesktop/freebsd-ports/commits/feature/xserver-1.20
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
(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.
(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.
(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 ?
(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.
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
(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).
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.
(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.
(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
(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
(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.
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.
(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.
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".
(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"
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
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.
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
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!
(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?
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
(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 .
udev vs devd - what pros/cons?
Great, it finally happened. Thanks to everyone who made this possible!
+1 :-)
it looks like FIXDRM issue is still here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244306
(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
(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?
Created attachment 211907 [details] restore xf86DisableRandR Lena, does the attached patch help?
Maybe it's a good idea to create a new port for legacy xorg-server?
(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.
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
(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
(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...
(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
(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.
(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.
All my systems run with nvidia-driver-390-390.132
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
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
(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
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
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
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
Sorry. Forgot to mention: Fresh install of 13/current from 2 weeks ago. ports from head yesterday.
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?
304 doesn't support xorg 1.20
(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.
(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
(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
(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
(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.
(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).
(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
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
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.
(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.
(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.
(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.
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)
(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)
(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
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.
> 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?
(In reply to Lena from comment #189) xf86-video-nv, xf86-video-vesa or just throw it away.
(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.
(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
(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.
(In reply to Alex S from comment #193) That comment was uncalled for, :(
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.
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.