Most changes has been committed with r487789
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 22 2018
Oct 12 2017
Small fix
Evdev headers now are downloaded from torvalds/linux github repository not from libevdev port
PR/196678 is excluded as it should be the part of future xorg-server update proposed by mrezny@. (I hope it will happen, better sooner than later)
devel/libevdev, devel/py-evdev, devel/evemu & x11/libinput versions are bumped
PR/219264 (x11/libwacom: install the profiles of tablets) is leaked into the patch, but it can be removed if necessary
Jun 2 2017
IMO it is far beyond accepted level of uglyness. Making high-profile API depend on the compiler settings does not make the API usable. Also, does this trick work for C++ ? The union vs. padding either would not work or require even more magic for big endian arches.
I did not changed type of udata, the later would cause serious API incompatibilities.
May 23 2017
Abandoned in favour of D10265
Finally I found out how to abandon revision after some googling. It is not very intuitive.
May 17 2017
May 16 2017
IMO, this driver can be written in generic way
May 14 2017
Change is obsolete.
After some discussion with bde@ (on arch@ and private) it is turned out that nothing but Giant can be used to serialize access to I8042 ports currently.
Although it is possible to move psm softc from Giant to private mutex that would complicate things as all calls to I8042 should be done with Giant taken so psm mutex should be released at this time.
Change is obsolete.
After some discussion with bde@ (on arch@ and private) it is turned out that nothing but Giant can be used to serialize access to I8042 ports currently.
May 13 2017
Giant-locked version of the patch.
After some discussion with bde@ (on arch@ and private) it is turned out that nothing but Giant can be used to serialize access to I8042 ports currently.
This version obsoletes part1 and part2 and can be applied to unmodified CURRENT (and 11STABLE as well).
May 5 2017
could you email link to this review to freebsd-arch@
May 3 2017
"evdev support part 4" -> "evdev support part 0". Part 3 is dependent on some of these changes.
Apr 19 2017
Device names and product IDs of supported touchpads and trackpoints are updated to match Linux
Device names and product IDs of supported touchpads and trackpoints are updated to match Linux
Apr 16 2017
Reduce default synaptics touch sensitivity to make libinput tap detection more reliable.
Remove extraneous checks for relative motion events with value = 0. It is already done inside evdev.ko
Apr 3 2017
Changes are not independent (evdev depends on psm that depends on atkbdc), but there should be no errors at each step if they are applied one by one in ascending order
I had split them and created following reviews: https://reviews.freebsd.org/D10263, https://reviews.freebsd.org/D10264, https://reviews.freebsd.org/D10265 and https://reviews.freebsd.org/D10266
Last (10266) change is not split on independent parts yet. I will do that ASAP.
Mar 30 2017
I will broadcast CFT of this change on current- and mobile- lists in couple of days
Feb 21 2017
Yep, I was basing this change off of another driver that had a TODO there. I can actually parse it out though.
We do not provide some of ioctls (EVIOCGMASK & EVIOCSMASK) in kernel but
- There is userspace evdev implementation in ports tree (multimedia/webcamd) that handles them
- libevdev has some built in runtime features checks, e.g. it can query uinput protocol version (4 or 5) at runtime and choose appropriate ioctls. It currently do not have checks for EVIOC*MASK as do not wrap these services yet.
- libevdev usually wants recent headers to compile and tries to do #2 to work on older kernels
- Newer versions of headers contains newer event codes definitions that can be used with older kernels.
- If some software does want check supported ioctls at compile time it always possible to replace #include <linux/input.h> with #include <dev/evdev/input.h> in sources
I suggest to change headers ports name from libevdev-headers to just evdev-headers to clear this confusion
These headers are not library interface, but a kernel one. I extract them from libevdev not from linux kernel because libevdev is main consumer, always contains updated version and have relatively small filesize.
FreeBSD have native versions of these headers located in /usr/include/dev/evdev/ but as evdev interface evolves faster than our release cycle, they have limited usage in ports system.
Do you have sample of description of absolute device obtained on Linux with evemu-record or similar tool?
Feb 20 2017
In D7588#200149, @hselasky wrote:Hi,
What tests have you done?
PR/217248 - devel/libevdev: update to 1.5.6, fix outdated and broken evdev headers (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217248) has been created
Feb 19 2017
Move sed scripts for patching evdev headers to devel/libevdev and remove Mk/Uses/evdev.mk
Chase for xorg-server 1.18.4 update
Jan 24 2017
Jan 18 2017
Ports versions updated.
Diff rebased to current ports tree.
Not very extensively tested.
Nov 20 2016
Full-context diff
Nov 3 2016
Oct 30 2016
Do not report leds and repeat settings changes if kern.evdev.rcpt_mask sysctl value forbids that
Oct 29 2016
Oct 16 2016
Copy serial line configuration black magic from xf86-input-keyboard driver to xorg-server console configuration routine.
This allows prevent interference between terminal and xorg-server screen output when xorg is configured for evdev rather than terminal keyboard input.
Sep 21 2016
For reasons unclear to me FreeBSD does not use const modifier in similar cases. Grep sources for e.g. struct fileops, struct vop_vector, struct cdevsw, struct filterops declarations.
Sep 19 2016
ukbd(4): D7957
Sep 18 2016
- Remove webcamd from patch as it has been commited already
- libevdev 1.5.2->1.5.4
- Make multimedia/v4l_compat not depending on devel/libevdev-headers. Fix couple (all?) of ports to be compileable with this change.
Sep 14 2016
Sep 13 2016
In D7863#163337, @hselasky wrote:Have you thought about if it is better to have a MODULE_DEPEND on evdev.ko instead of all the ifdefs?
I thought of it but was stopped every time at sysmouse support as it is part of sc/vt and can not be kldloaded thus making evdev always loaded.
But I didn`t think about making sysmouse evdev support as module itself till now.
In D6998#163131, @emaste wrote:A little note, you can use the review number by itself (e.g. just D7863) and Phabricator will automatically add the link, and also reference this review from the one mentioned.
Thanks for pointing that out.
Sep 12 2016
In D6998#163107, @gonzo wrote:Vladimir, could you submit devices' evdev patches to differential? I suggest starting with USB devs, one device per review. I talked to Hans, he's OK with reviewing them
Sep 7 2016
In D6998#162251, @dumbbell wrote:In D6998#162223, @gonzo wrote:I guess it's time to commit this change. Jean-Sébastien would you commit it as a maintainer of all things input? Or if you don't have spare cycles I can do it myself.
I barely improved Synaptics support years ago. But I have a lot of interest in this topic.
Diff updated. It would be nice to commit https://reviews.freebsd.org/D7588 as well to allow multimedia/webcamd coexistence. 11-servers/xorg-server change can be postponed if someone thinks it too radical
Fix compiling with INVARIANTS disabled
Fix EVIOCGKEYCODE* ioctls direction
Split input.h on input.h(ioctls) and input-event-codes.h(event codes) like Linux did
Clear uinput device state after UI_DEV_DESTROY ioctl
Declare uinput as kernel module. Not kldload-able yet.
Reduce KPI(evdev.h) on API (input.h) dependence through removing struct input_absinfo from evdev_support_abs() arguments
This revision fails to compile with INVARIANTS disabled. I fixed that in my repo and I`m going to update diff in this review in hour or two with couple others minor fixes
Aug 29 2016
In D6998#159709, @hselasky wrote:If kernel drivers are supposed to supply events, then it is a problem to use an SX lock, because many drivers hold a mutex when they generate events. And locking SX after MTX is an issue. If this layer is only intended for loopback of events via user-space it is fine.
Evdev ports support is submitted for review here: https://reviews.freebsd.org/D7588
Aug 27 2016
In D7588#157689, @kwm wrote:So you have a, simple if possible, way to test the above changes?
Mk/Uses/evdev.mk evdev ARGS comments reworded
multimedia/webcamd updated to 4.8.0.4
Aug 23 2016
Aug 22 2016
In D7588#157689, @kwm wrote:So you have a, simple if possible, way to test the above changes?
If you want to test above changes "in hardware" I can try to make webcamd patch to workaround "missing usb serial number" issue so it will be possible to attach webcamd to usb keyboards and mouses. Webcamd interface should exactly match its in-kernel counterpart since v.4.8.0.2
Aug 21 2016
In D7588#157689, @kwm wrote:So you have a, simple if possible, way to test the above changes?
Remove leaked file
Aug 19 2016
Aug 15 2016
In D6998#155829, @hselasky wrote:I've now updated the SVN version of webcamd with the input.h and ioctl.h patches you've provided.
Thank you!
Aug 13 2016
In D6998#155649, @hselasky wrote:I understand what you mean. Could you change the Linux IOCTL header file in your webcamd patch instead of redirecting the IOCTLs in the IOCTL handler? I think then you only need to add code for the generic VOID IOCTL copy-in of the argument and you can keep the IOCTL of type VOID?
Aug 12 2016
In D6998#155552, @kmacy wrote:I don't understand this restriction. cxgb(9) and other drivers I've worked on are perfectly capable of handling nested copyins.
Would it be better to integrate this driver by way of the linuxkpi where this isn't considered a problem?
In D6998#155480, @wulf_cicgroup.ru wrote:In D6998#155472, @hselasky wrote:Can this be changed so we avoid patching webcamd?
Just now webcamd should return EFAULT on these ioctls
After switching outer headers to use IOWINT they should return EINVAL or something similar
And after both patching webcamd and switching to IOWINT they should start to workSo with avoiding of patching you would not make things worse
In D6998#155472, @hselasky wrote:Can this be changed so we avoid patching webcamd?
In D6998#155472, @hselasky wrote:What is the motivation behind using IOWINT() for FreeBSD IOCTLs and IOW(xxx, int) for Linux ones. Does this mean we are not binary compatible with Linux? Can this be changed so we avoid patching webcamd?
Aug 8 2016
In D6998#154695, @hselasky wrote:
In D6998#154695, @hselasky wrote:I need to patch webcamd and figure out how I can dynamically detect if this EVDEV driver is loaded or not.
Committing this AS-IS will break /usr/ports/multimedia/webcamd which many people use.
Aug 7 2016
Ooops. Forgot to attach evdev_private.h
- split evdev.h header on public and private parts
- make debug messages configurable on config stage as Adrian suggested
- uinput locking reworked (userspace calls are fully serialized now)
- some small fixes like EV_EOF/POLLHUP on revoked/detached device
In D6998#154470, @adrian wrote:What's it been tested on/with ?
Jul 4 2016
In D6998#147849, @hselasky wrote:When your /dev/uinput device closes, does it wakeup the children devices and make them return an error?
Yes it does wakeup and than returns ENODEV on every file operation like Linux does
Case I false-reported happened with cuse-backed devices not with uinput ones
In D6998#147849, @hselasky wrote:When your /dev/uinput device closes, does it wakeup the children devices and make them return an error? That might be the problem. Or is the xorg-event driver not checking read() / poll() for errors. Detach needs to work. Can you investigate?
Jul 2 2016
In D6998#147567, @hselasky wrote:cuse bug: Can you see if any devices have opened /dev/input handles to evdevs using fstat? There should be no bug there.
In D6998#146760, @hselasky wrote:Can you propose a patch for webcamd to use the kernel's /dev/input/eventX layer?
Done
Implements passing events from user to userspace drivers like webcamd via uinput interface
Jun 30 2016
In D6998#147328, @hselasky wrote:
Jun 29 2016
In D6998#146955, @hselasky wrote:Thank you for your patch. I'll see if I can give it a spin.
Thank you too. I tried it and it found it working (after some fixes).
Jun 28 2016
In D6998#146797, @emaste wrote:Next time please upload with full context -- see https://wiki.freebsd.org/CodeReview. For git, it's just git diff -U9999, for svn svn diff --diff-cmd=diff -x -U999999. No need to re-upload now just to include the context but please do so if/when you have other changes to upload in this review.
In D6998#146760, @hselasky wrote:Can you propose a patch for webcamd to use the kernel's /dev/input/eventX layer?
Many people are using it on their desktops, so this must work smoothly.
Could you try following patch? http://195.170.219.74/webcamd-20160628.patch
It is compile tested only due to lack of webcam-supported hardware so it can do something other than intended. It should create both cuse-cdev as /dev/input/webcamdXX and its uinput alter-ego as /dev/input/eventXX
In D6998#146718, @hselasky wrote:Are you aware about the following PR and attached patches:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678
In D6998#146721, @hselasky wrote:Can you propose a solution how webcamd and kernel's evdev can co-exist in /dev/input? For example
Use different node names? eventXX for userspace bsdeventYY for the kernel?
Best solution is to use uinput interface instead of cuse
In D6998#146685, @hselasky wrote:Hi,
Did you test that your implementation does not interfere with /usr/ports/multimedia/webcamd
It tries to choose next device unit number if make_dev returned EEXISTS but real coexistence has not been tested
Is webcamd able to create dummy event device? Is webcamd supports a case when /dev/input/ already populated?
and the V4L linux compat files?
Both (reviewed and v4linux) headers can not be #included at one time, but they are compatible.
Really, I use patched V4L linux compat headers for userland evdev stack parts to ease of porting not headers from this review:
http://195.170.219.74/evdev-ports-20160628.diff
Jun 27 2016
Remove some leaked lines