Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf

2018-11-12 Thread Niclas Zeising

On 11/13/18 7:10 AM, Kevin Bowling wrote:

ppc64 will be the next arch after amd64 to get modern graphics
(https://github.com/POWER9BSD/freebsd/commits/projects/lkpi) but we
like the tier-2 status for now and will replay changes from amd64
GENERIC once I'm able to test.

FWIW evdev is the standard with libinput for X11 under Linux.  It's
useful for modern trackpads and has no downsides for traditional
keyboards and mice under X11.  It's also a requisite for Wayland.  So
I am happy to see this change, thanks Niclas!.



This is great!
Let me and the rest of the graphics team know if we can help in any way.
I have no problem enabling evdev support in ppc64 (or any other arches) 
if it's tested at least a little.
The only reason I only enabled it for i386 and amd64 is that those are 
the platforms I have available myself.

Regards
--
Niclas Zeising
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf

2018-11-12 Thread Niclas Zeising

On 11/13/18 1:49 AM, Warner Losh wrote:

On Mon, Nov 12, 2018 at 5:30 PM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:


On Mon, Nov 12, 2018, 3:12 PM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net wrote:


Author: zeising (doc,ports committer)
Date: Mon Nov 12 21:01:28 2018
New Revision: 340387
URL: https://svnweb.freebsd.org/changeset/base/340387

Log:
   Add evdev support to amd64 and i386 kernels

   Include evdev support and drivers in the amd64 and i386 GENERIC and

MINIMAL

   kernels.  Evdev is used by X and wayland to handle input devices,

and

this

   change, together with upcomming changes in ports will make us

handle

input

   devices better in graphical UIs.


Well these "upcomming" changes in ports effect aarch64 and powerpc
who are also consumers of X?



Likely. Though there is little experience with them, so we don't know if

it

is even safe to turn them on there yet. This has taken 6 months to get
stable on x86 due to its fragile console locking protocol. Similar time

has

not been invested elsewhere, so until that happens, we should keep them

off

by default. Otherwise we run the risk of destabilizing these platforms,
even for people who don't use X. As tier 2 platforms, this has been how
we've traditionally approached risk. Even though aarch64 is approaching
tier1 status overall, in graphics it is still lagging.


 From some place aarch64 is already a tier1 platform, specifically
it is listed as such in the pkg.freebsd.org package download page.



Graphics on aarch64 is tier 2, and will remain tier 2 for the foreseeable
future. Tier 1 support requires that we leverage other people's drivers,
and we can't easily do that w/o a good linux compat layer. The structure of
FreeBSD and Linux are just enough different that doing so is somewhat
tricky and labor intensive. This is especially true for the acceleration
features. Basic framebuffer support isn't terribly hard, but to get good 2d
and 3d acceleration, we'll likely need to run upstream vendor's code (which
in many cases is available only as a binary blob + linux glue).



My real concern here is that it sounded like changes to what are
in the ports/packages are going to be made in such a way that you
are required to have evdev to use them.  If this suddently becomes
mandatory to be able to use X we need to ensure that this code
(evdev) does infact work on aarch64 and others before such changes are
put in place.  My reading here is that this code is only avaliable
as static compile into the kernel, aka no moduleto load, making this
a non-trivial road block to rpi3, etc users.



This is just for touchscreen support on x86, which requires evdev to work
well. Whatever works today won't change. However, without a lot of testing,
I'm hesitant to blindly enable it on aarch64. Once that changes, we can
turn it on, but until then it would be unwise. And evdev can be turned off
on a per-platform basis in the packages / ports tree should the need arise.
I don't think this is going to be an issue.



Hi!
This change makes it easier, and in some case possible, to use certain 
input devices, such as touchscreens, input tablets and so on. It will 
make it easier to use things like two finger scrolling or horizontal 
scrolling on touchpads, for instance.
Using evdev and libinput (from ports) is a prerequisite for Wayland, and 
useful for X, however, for X the old input drivers are not going away, 
and can still be used on architectures without evdev.
The input stack (for graphical environments) in FreeBSD is lagging 
behind Linux, and this is a first step to get it at least a little bit 
closer in terms of support.


With regards to other architectures, I only have access to amd64 and to 
some extent i386, and only enabled the drivers there.  I have no problem 
with enabling this on further architectures if I get help testing, or 
hardware to test on.


As stated, this won't cause regressions on these platforms, the old 
input device drivers (xf86-input-*) won't go anywhere in a hurry, if 
ever, and is still available for use.


I hope this clears things up a little.
Regards
--
Niclas Zeising
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf

2018-11-12 Thread Kevin Bowling
ppc64 will be the next arch after amd64 to get modern graphics
(https://github.com/POWER9BSD/freebsd/commits/projects/lkpi) but we
like the tier-2 status for now and will replay changes from amd64
GENERIC once I'm able to test.

FWIW evdev is the standard with libinput for X11 under Linux.  It's
useful for modern trackpads and has no downsides for traditional
keyboards and mice under X11.  It's also a requisite for Wayland.  So
I am happy to see this change, thanks Niclas!.

Regards,
Kevin
On Mon, Nov 12, 2018 at 5:50 PM Warner Losh  wrote:
>
> On Mon, Nov 12, 2018 at 5:30 PM Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
>
> > > On Mon, Nov 12, 2018, 3:12 PM Rodney W. Grimes <
> > > free...@pdx.rh.cn85.dnsmgr.net wrote:
> > >
> > > > > Author: zeising (doc,ports committer)
> > > > > Date: Mon Nov 12 21:01:28 2018
> > > > > New Revision: 340387
> > > > > URL: https://svnweb.freebsd.org/changeset/base/340387
> > > > >
> > > > > Log:
> > > > >   Add evdev support to amd64 and i386 kernels
> > > > >
> > > > >   Include evdev support and drivers in the amd64 and i386 GENERIC and
> > > > MINIMAL
> > > > >   kernels.  Evdev is used by X and wayland to handle input devices,
> > and
> > > > this
> > > > >   change, together with upcomming changes in ports will make us
> > handle
> > > > input
> > > > >   devices better in graphical UIs.
> > > >
> > > > Well these "upcomming" changes in ports effect aarch64 and powerpc
> > > > who are also consumers of X?
> > > >
> > >
> > > Likely. Though there is little experience with them, so we don't know if
> > it
> > > is even safe to turn them on there yet. This has taken 6 months to get
> > > stable on x86 due to its fragile console locking protocol. Similar time
> > has
> > > not been invested elsewhere, so until that happens, we should keep them
> > off
> > > by default. Otherwise we run the risk of destabilizing these platforms,
> > > even for people who don't use X. As tier 2 platforms, this has been how
> > > we've traditionally approached risk. Even though aarch64 is approaching
> > > tier1 status overall, in graphics it is still lagging.
> >
> > From some place aarch64 is already a tier1 platform, specifically
> > it is listed as such in the pkg.freebsd.org package download page.
> >
>
> Graphics on aarch64 is tier 2, and will remain tier 2 for the foreseeable
> future. Tier 1 support requires that we leverage other people's drivers,
> and we can't easily do that w/o a good linux compat layer. The structure of
> FreeBSD and Linux are just enough different that doing so is somewhat
> tricky and labor intensive. This is especially true for the acceleration
> features. Basic framebuffer support isn't terribly hard, but to get good 2d
> and 3d acceleration, we'll likely need to run upstream vendor's code (which
> in many cases is available only as a binary blob + linux glue).
>
>
> > My real concern here is that it sounded like changes to what are
> > in the ports/packages are going to be made in such a way that you
> > are required to have evdev to use them.  If this suddently becomes
> > mandatory to be able to use X we need to ensure that this code
> > (evdev) does infact work on aarch64 and others before such changes are
> > put in place.  My reading here is that this code is only avaliable
> > as static compile into the kernel, aka no moduleto load, making this
> > a non-trivial road block to rpi3, etc users.
> >
>
> This is just for touchscreen support on x86, which requires evdev to work
> well. Whatever works today won't change. However, without a lot of testing,
> I'm hesitant to blindly enable it on aarch64. Once that changes, we can
> turn it on, but until then it would be unwise. And evdev can be turned off
> on a per-platform basis in the packages / ports tree should the need arise.
> I don't think this is going to be an issue.
>
> Warner
>
>
> > > Warner
> > >
> > >
> > > >   Reviewed by:wulf, bapt, imp
> > > > >   Approved by:imp
> > > > >   Differential Revision:  https://reviews.freebsd.org/D17912
> > > > >
> > > > > Modified:
> > > > >   head/sys/amd64/conf/GENERIC
> > > > >   head/sys/amd64/conf/MINIMAL
> > > > >   head/sys/i386/conf/GENERIC
> > > > >   head/sys/i386/conf/MINIMAL
> > > > >
> > > > > Modified: head/sys/amd64/conf/GENERIC
> > > > >
> > > >
> > ==
> > > > > --- head/sys/amd64/conf/GENERIC   Mon Nov 12 20:44:22 2018
> > > > (r340386)
> > > > > +++ head/sys/amd64/conf/GENERIC   Mon Nov 12 21:01:28 2018
> > > > (r340387)
> > > > > @@ -372,3 +372,8 @@ devicevmx #
> > VMware
> > > > VMXNET3 Ethernet
> > > > >
> > > > >  # Netmap provides direct access to TX/RX rings on supported NICs
> > > > >  device   netmap  # netmap(4) support
> > > > > +
> > > > > +# evdev interface
> > > > > +options  EVDEV_SUPPORT   # evdev support in legacy
> > drivers
> > > > > 

Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf

2018-11-12 Thread Warner Losh
On Mon, Nov 12, 2018 at 5:30 PM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Mon, Nov 12, 2018, 3:12 PM Rodney W. Grimes <
> > free...@pdx.rh.cn85.dnsmgr.net wrote:
> >
> > > > Author: zeising (doc,ports committer)
> > > > Date: Mon Nov 12 21:01:28 2018
> > > > New Revision: 340387
> > > > URL: https://svnweb.freebsd.org/changeset/base/340387
> > > >
> > > > Log:
> > > >   Add evdev support to amd64 and i386 kernels
> > > >
> > > >   Include evdev support and drivers in the amd64 and i386 GENERIC and
> > > MINIMAL
> > > >   kernels.  Evdev is used by X and wayland to handle input devices,
> and
> > > this
> > > >   change, together with upcomming changes in ports will make us
> handle
> > > input
> > > >   devices better in graphical UIs.
> > >
> > > Well these "upcomming" changes in ports effect aarch64 and powerpc
> > > who are also consumers of X?
> > >
> >
> > Likely. Though there is little experience with them, so we don't know if
> it
> > is even safe to turn them on there yet. This has taken 6 months to get
> > stable on x86 due to its fragile console locking protocol. Similar time
> has
> > not been invested elsewhere, so until that happens, we should keep them
> off
> > by default. Otherwise we run the risk of destabilizing these platforms,
> > even for people who don't use X. As tier 2 platforms, this has been how
> > we've traditionally approached risk. Even though aarch64 is approaching
> > tier1 status overall, in graphics it is still lagging.
>
> From some place aarch64 is already a tier1 platform, specifically
> it is listed as such in the pkg.freebsd.org package download page.
>

Graphics on aarch64 is tier 2, and will remain tier 2 for the foreseeable
future. Tier 1 support requires that we leverage other people's drivers,
and we can't easily do that w/o a good linux compat layer. The structure of
FreeBSD and Linux are just enough different that doing so is somewhat
tricky and labor intensive. This is especially true for the acceleration
features. Basic framebuffer support isn't terribly hard, but to get good 2d
and 3d acceleration, we'll likely need to run upstream vendor's code (which
in many cases is available only as a binary blob + linux glue).


> My real concern here is that it sounded like changes to what are
> in the ports/packages are going to be made in such a way that you
> are required to have evdev to use them.  If this suddently becomes
> mandatory to be able to use X we need to ensure that this code
> (evdev) does infact work on aarch64 and others before such changes are
> put in place.  My reading here is that this code is only avaliable
> as static compile into the kernel, aka no moduleto load, making this
> a non-trivial road block to rpi3, etc users.
>

This is just for touchscreen support on x86, which requires evdev to work
well. Whatever works today won't change. However, without a lot of testing,
I'm hesitant to blindly enable it on aarch64. Once that changes, we can
turn it on, but until then it would be unwise. And evdev can be turned off
on a per-platform basis in the packages / ports tree should the need arise.
I don't think this is going to be an issue.

Warner


> > Warner
> >
> >
> > >   Reviewed by:wulf, bapt, imp
> > > >   Approved by:imp
> > > >   Differential Revision:  https://reviews.freebsd.org/D17912
> > > >
> > > > Modified:
> > > >   head/sys/amd64/conf/GENERIC
> > > >   head/sys/amd64/conf/MINIMAL
> > > >   head/sys/i386/conf/GENERIC
> > > >   head/sys/i386/conf/MINIMAL
> > > >
> > > > Modified: head/sys/amd64/conf/GENERIC
> > > >
> > >
> ==
> > > > --- head/sys/amd64/conf/GENERIC   Mon Nov 12 20:44:22 2018
> > > (r340386)
> > > > +++ head/sys/amd64/conf/GENERIC   Mon Nov 12 21:01:28 2018
> > > (r340387)
> > > > @@ -372,3 +372,8 @@ devicevmx #
> VMware
> > > VMXNET3 Ethernet
> > > >
> > > >  # Netmap provides direct access to TX/RX rings on supported NICs
> > > >  device   netmap  # netmap(4) support
> > > > +
> > > > +# evdev interface
> > > > +options  EVDEV_SUPPORT   # evdev support in legacy
> drivers
> > > > +device   evdev   # input event device
> > > support
> > > > +device   uinput  # install /dev/uinput
> cdev
> > > >
> > > > Modified: head/sys/amd64/conf/MINIMAL
> > > >
> > >
> ==
> > > > --- head/sys/amd64/conf/MINIMAL   Mon Nov 12 20:44:22 2018
> > > (r340386)
> > > > +++ head/sys/amd64/conf/MINIMAL   Mon Nov 12 21:01:28 2018
> > > (r340387)
> > > > @@ -147,3 +147,8 @@ devicebpf #
> Berkeley
> > > packet filter
> > > >  # NOTE: XENHVM depends on xenpci.  They must be added or removed
> > > together.
> > > >  options  XENHVM  # Xen HVM kernel 

Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf

2018-11-12 Thread Rodney W. Grimes
> On Mon, Nov 12, 2018, 3:12 PM Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net wrote:
> 
> > > Author: zeising (doc,ports committer)
> > > Date: Mon Nov 12 21:01:28 2018
> > > New Revision: 340387
> > > URL: https://svnweb.freebsd.org/changeset/base/340387
> > >
> > > Log:
> > >   Add evdev support to amd64 and i386 kernels
> > >
> > >   Include evdev support and drivers in the amd64 and i386 GENERIC and
> > MINIMAL
> > >   kernels.  Evdev is used by X and wayland to handle input devices, and
> > this
> > >   change, together with upcomming changes in ports will make us handle
> > input
> > >   devices better in graphical UIs.
> >
> > Well these "upcomming" changes in ports effect aarch64 and powerpc
> > who are also consumers of X?
> >
> 
> Likely. Though there is little experience with them, so we don't know if it
> is even safe to turn them on there yet. This has taken 6 months to get
> stable on x86 due to its fragile console locking protocol. Similar time has
> not been invested elsewhere, so until that happens, we should keep them off
> by default. Otherwise we run the risk of destabilizing these platforms,
> even for people who don't use X. As tier 2 platforms, this has been how
> we've traditionally approached risk. Even though aarch64 is approaching
> tier1 status overall, in graphics it is still lagging.

>From some place aarch64 is already a tier1 platform, specifically
it is listed as such in the pkg.freebsd.org package download page.

My real concern here is that it sounded like changes to what are
in the ports/packages are going to be made in such a way that you
are required to have evdev to use them.  If this suddently becomes
mandatory to be able to use X we need to ensure that this code
(evdev) does infact work on aarch64 and others before such changes are
put in place.  My reading here is that this code is only avaliable
as static compile into the kernel, aka no moduleto load, making this
a non-trivial road block to rpi3, etc users.

> Warner
> 
> 
> >   Reviewed by:wulf, bapt, imp
> > >   Approved by:imp
> > >   Differential Revision:  https://reviews.freebsd.org/D17912
> > >
> > > Modified:
> > >   head/sys/amd64/conf/GENERIC
> > >   head/sys/amd64/conf/MINIMAL
> > >   head/sys/i386/conf/GENERIC
> > >   head/sys/i386/conf/MINIMAL
> > >
> > > Modified: head/sys/amd64/conf/GENERIC
> > >
> > ==
> > > --- head/sys/amd64/conf/GENERIC   Mon Nov 12 20:44:22 2018
> > (r340386)
> > > +++ head/sys/amd64/conf/GENERIC   Mon Nov 12 21:01:28 2018
> > (r340387)
> > > @@ -372,3 +372,8 @@ devicevmx # VMware
> > VMXNET3 Ethernet
> > >
> > >  # Netmap provides direct access to TX/RX rings on supported NICs
> > >  device   netmap  # netmap(4) support
> > > +
> > > +# evdev interface
> > > +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> > > +device   evdev   # input event device
> > support
> > > +device   uinput  # install /dev/uinput cdev
> > >
> > > Modified: head/sys/amd64/conf/MINIMAL
> > >
> > ==
> > > --- head/sys/amd64/conf/MINIMAL   Mon Nov 12 20:44:22 2018
> > (r340386)
> > > +++ head/sys/amd64/conf/MINIMAL   Mon Nov 12 21:01:28 2018
> > (r340387)
> > > @@ -147,3 +147,8 @@ devicebpf # Berkeley
> > packet filter
> > >  # NOTE: XENHVM depends on xenpci.  They must be added or removed
> > together.
> > >  options  XENHVM  # Xen HVM kernel infrastructure
> > >  device   xenpci  # Xen HVM Hypervisor
> > services driver
> > > +
> > > +# evdev interface
> > > +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> > > +device   evdev   # input event device
> > support
> > > +device   uinput  # install /dev/uinput cdev
> > >
> > > Modified: head/sys/i386/conf/GENERIC
> > >
> > ==
> > > --- head/sys/i386/conf/GENERICMon Nov 12 20:44:22 2018
> > (r340386)
> > > +++ head/sys/i386/conf/GENERICMon Nov 12 21:01:28 2018
> > (r340387)
> > > @@ -366,3 +366,8 @@ devicexenpci  # Xen HVM
> > Hypervisor services driver
> > >
> > >  # VMware support
> > >  device   vmx # VMware VMXNET3 Ethernet
> > > +
> > > +# evdev interface
> > > +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> > > +device   evdev   # input event device
> > support
> > > +device   uinput  # install /dev/uinput cdev
> > >
> > > Modified: head/sys/i386/conf/MINIMAL
> > >
> > 

Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf

2018-11-12 Thread Warner Losh
On Mon, Nov 12, 2018, 3:12 PM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net wrote:

> > Author: zeising (doc,ports committer)
> > Date: Mon Nov 12 21:01:28 2018
> > New Revision: 340387
> > URL: https://svnweb.freebsd.org/changeset/base/340387
> >
> > Log:
> >   Add evdev support to amd64 and i386 kernels
> >
> >   Include evdev support and drivers in the amd64 and i386 GENERIC and
> MINIMAL
> >   kernels.  Evdev is used by X and wayland to handle input devices, and
> this
> >   change, together with upcomming changes in ports will make us handle
> input
> >   devices better in graphical UIs.
>
> Well these "upcomming" changes in ports effect aarch64 and powerpc
> who are also consumers of X?
>

Likely. Though there is little experience with them, so we don't know if it
is even safe to turn them on there yet. This has taken 6 months to get
stable on x86 due to its fragile console locking protocol. Similar time has
not been invested elsewhere, so until that happens, we should keep them off
by default. Otherwise we run the risk of destabilizing these platforms,
even for people who don't use X. As tier 2 platforms, this has been how
we've traditionally approached risk. Even though aarch64 is approaching
tier1 status overall, in graphics it is still lagging.

Warner


>   Reviewed by:wulf, bapt, imp
> >   Approved by:imp
> >   Differential Revision:  https://reviews.freebsd.org/D17912
> >
> > Modified:
> >   head/sys/amd64/conf/GENERIC
> >   head/sys/amd64/conf/MINIMAL
> >   head/sys/i386/conf/GENERIC
> >   head/sys/i386/conf/MINIMAL
> >
> > Modified: head/sys/amd64/conf/GENERIC
> >
> ==
> > --- head/sys/amd64/conf/GENERIC   Mon Nov 12 20:44:22 2018
> (r340386)
> > +++ head/sys/amd64/conf/GENERIC   Mon Nov 12 21:01:28 2018
> (r340387)
> > @@ -372,3 +372,8 @@ devicevmx # VMware
> VMXNET3 Ethernet
> >
> >  # Netmap provides direct access to TX/RX rings on supported NICs
> >  device   netmap  # netmap(4) support
> > +
> > +# evdev interface
> > +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> > +device   evdev   # input event device
> support
> > +device   uinput  # install /dev/uinput cdev
> >
> > Modified: head/sys/amd64/conf/MINIMAL
> >
> ==
> > --- head/sys/amd64/conf/MINIMAL   Mon Nov 12 20:44:22 2018
> (r340386)
> > +++ head/sys/amd64/conf/MINIMAL   Mon Nov 12 21:01:28 2018
> (r340387)
> > @@ -147,3 +147,8 @@ devicebpf # Berkeley
> packet filter
> >  # NOTE: XENHVM depends on xenpci.  They must be added or removed
> together.
> >  options  XENHVM  # Xen HVM kernel infrastructure
> >  device   xenpci  # Xen HVM Hypervisor
> services driver
> > +
> > +# evdev interface
> > +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> > +device   evdev   # input event device
> support
> > +device   uinput  # install /dev/uinput cdev
> >
> > Modified: head/sys/i386/conf/GENERIC
> >
> ==
> > --- head/sys/i386/conf/GENERICMon Nov 12 20:44:22 2018
> (r340386)
> > +++ head/sys/i386/conf/GENERICMon Nov 12 21:01:28 2018
> (r340387)
> > @@ -366,3 +366,8 @@ devicexenpci  # Xen HVM
> Hypervisor services driver
> >
> >  # VMware support
> >  device   vmx # VMware VMXNET3 Ethernet
> > +
> > +# evdev interface
> > +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> > +device   evdev   # input event device
> support
> > +device   uinput  # install /dev/uinput cdev
> >
> > Modified: head/sys/i386/conf/MINIMAL
> >
> ==
> > --- head/sys/i386/conf/MINIMALMon Nov 12 20:44:22 2018
> (r340386)
> > +++ head/sys/i386/conf/MINIMALMon Nov 12 21:01:28 2018
> (r340387)
> > @@ -148,3 +148,8 @@ devicebpf # Berkeley
> packet filter
> >  # NOTE: XENHVM depends on xenpci.  They must be added or removed
> together.
> >  options  XENHVM  # Xen HVM kernel infrastructure
> >  device   xenpci  # Xen HVM Hypervisor
> services driver
> > +
> > +# evdev interface
> > +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> > +device   evdev   # input event device
> support
> > +device   uinput  # install /dev/uinput cdev
> >
> >
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
>

Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf

2018-11-12 Thread Rodney W. Grimes
> Author: zeising (doc,ports committer)
> Date: Mon Nov 12 21:01:28 2018
> New Revision: 340387
> URL: https://svnweb.freebsd.org/changeset/base/340387
> 
> Log:
>   Add evdev support to amd64 and i386 kernels
>   
>   Include evdev support and drivers in the amd64 and i386 GENERIC and MINIMAL
>   kernels.  Evdev is used by X and wayland to handle input devices, and this
>   change, together with upcomming changes in ports will make us handle input
>   devices better in graphical UIs.

Well these "upcomming" changes in ports effect aarch64 and powerpc
who are also consumers of X?

>   Reviewed by:wulf, bapt, imp
>   Approved by:imp
>   Differential Revision:  https://reviews.freebsd.org/D17912
> 
> Modified:
>   head/sys/amd64/conf/GENERIC
>   head/sys/amd64/conf/MINIMAL
>   head/sys/i386/conf/GENERIC
>   head/sys/i386/conf/MINIMAL
> 
> Modified: head/sys/amd64/conf/GENERIC
> ==
> --- head/sys/amd64/conf/GENERIC   Mon Nov 12 20:44:22 2018
> (r340386)
> +++ head/sys/amd64/conf/GENERIC   Mon Nov 12 21:01:28 2018
> (r340387)
> @@ -372,3 +372,8 @@ devicevmx # VMware 
> VMXNET3 Ethernet
>  
>  # Netmap provides direct access to TX/RX rings on supported NICs
>  device   netmap  # netmap(4) support
> +
> +# evdev interface
> +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> +device   evdev   # input event device support
> +device   uinput  # install /dev/uinput cdev
> 
> Modified: head/sys/amd64/conf/MINIMAL
> ==
> --- head/sys/amd64/conf/MINIMAL   Mon Nov 12 20:44:22 2018
> (r340386)
> +++ head/sys/amd64/conf/MINIMAL   Mon Nov 12 21:01:28 2018
> (r340387)
> @@ -147,3 +147,8 @@ devicebpf # Berkeley 
> packet filter
>  # NOTE: XENHVM depends on xenpci.  They must be added or removed together.
>  options  XENHVM  # Xen HVM kernel infrastructure
>  device   xenpci  # Xen HVM Hypervisor services 
> driver
> +
> +# evdev interface
> +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> +device   evdev   # input event device support
> +device   uinput  # install /dev/uinput cdev
> 
> Modified: head/sys/i386/conf/GENERIC
> ==
> --- head/sys/i386/conf/GENERICMon Nov 12 20:44:22 2018
> (r340386)
> +++ head/sys/i386/conf/GENERICMon Nov 12 21:01:28 2018
> (r340387)
> @@ -366,3 +366,8 @@ devicexenpci  # Xen HVM 
> Hypervisor services driver
>  
>  # VMware support
>  device   vmx # VMware VMXNET3 Ethernet
> +
> +# evdev interface
> +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> +device   evdev   # input event device support
> +device   uinput  # install /dev/uinput cdev
> 
> Modified: head/sys/i386/conf/MINIMAL
> ==
> --- head/sys/i386/conf/MINIMALMon Nov 12 20:44:22 2018
> (r340386)
> +++ head/sys/i386/conf/MINIMALMon Nov 12 21:01:28 2018
> (r340387)
> @@ -148,3 +148,8 @@ devicebpf # Berkeley 
> packet filter
>  # NOTE: XENHVM depends on xenpci.  They must be added or removed together.
>  options  XENHVM  # Xen HVM kernel infrastructure
>  device   xenpci  # Xen HVM Hypervisor services 
> driver
> +
> +# evdev interface
> +options  EVDEV_SUPPORT   # evdev support in legacy drivers
> +device   evdev   # input event device support
> +device   uinput  # install /dev/uinput cdev
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r340387 - in head/sys: amd64/conf i386/conf

2018-11-12 Thread Niclas Zeising
Author: zeising (doc,ports committer)
Date: Mon Nov 12 21:01:28 2018
New Revision: 340387
URL: https://svnweb.freebsd.org/changeset/base/340387

Log:
  Add evdev support to amd64 and i386 kernels
  
  Include evdev support and drivers in the amd64 and i386 GENERIC and MINIMAL
  kernels.  Evdev is used by X and wayland to handle input devices, and this
  change, together with upcomming changes in ports will make us handle input
  devices better in graphical UIs.
  
  Reviewed by:  wulf, bapt, imp
  Approved by:  imp
  Differential Revision:https://reviews.freebsd.org/D17912

Modified:
  head/sys/amd64/conf/GENERIC
  head/sys/amd64/conf/MINIMAL
  head/sys/i386/conf/GENERIC
  head/sys/i386/conf/MINIMAL

Modified: head/sys/amd64/conf/GENERIC
==
--- head/sys/amd64/conf/GENERIC Mon Nov 12 20:44:22 2018(r340386)
+++ head/sys/amd64/conf/GENERIC Mon Nov 12 21:01:28 2018(r340387)
@@ -372,3 +372,8 @@ device  vmx # VMware 
VMXNET3 Ethernet
 
 # Netmap provides direct access to TX/RX rings on supported NICs
 device netmap  # netmap(4) support
+
+# evdev interface
+optionsEVDEV_SUPPORT   # evdev support in legacy drivers
+device evdev   # input event device support
+device uinput  # install /dev/uinput cdev

Modified: head/sys/amd64/conf/MINIMAL
==
--- head/sys/amd64/conf/MINIMAL Mon Nov 12 20:44:22 2018(r340386)
+++ head/sys/amd64/conf/MINIMAL Mon Nov 12 21:01:28 2018(r340387)
@@ -147,3 +147,8 @@ device  bpf # Berkeley 
packet filter
 # NOTE: XENHVM depends on xenpci.  They must be added or removed together.
 optionsXENHVM  # Xen HVM kernel infrastructure
 device xenpci  # Xen HVM Hypervisor services driver
+
+# evdev interface
+optionsEVDEV_SUPPORT   # evdev support in legacy drivers
+device evdev   # input event device support
+device uinput  # install /dev/uinput cdev

Modified: head/sys/i386/conf/GENERIC
==
--- head/sys/i386/conf/GENERIC  Mon Nov 12 20:44:22 2018(r340386)
+++ head/sys/i386/conf/GENERIC  Mon Nov 12 21:01:28 2018(r340387)
@@ -366,3 +366,8 @@ device  xenpci  # Xen HVM 
Hypervisor services driver
 
 # VMware support
 device vmx # VMware VMXNET3 Ethernet
+
+# evdev interface
+optionsEVDEV_SUPPORT   # evdev support in legacy drivers
+device evdev   # input event device support
+device uinput  # install /dev/uinput cdev

Modified: head/sys/i386/conf/MINIMAL
==
--- head/sys/i386/conf/MINIMAL  Mon Nov 12 20:44:22 2018(r340386)
+++ head/sys/i386/conf/MINIMAL  Mon Nov 12 21:01:28 2018(r340387)
@@ -148,3 +148,8 @@ device  bpf # Berkeley 
packet filter
 # NOTE: XENHVM depends on xenpci.  They must be added or removed together.
 optionsXENHVM  # Xen HVM kernel infrastructure
 device xenpci  # Xen HVM Hypervisor services driver
+
+# evdev interface
+optionsEVDEV_SUPPORT   # evdev support in legacy drivers
+device evdev   # input event device support
+device uinput  # install /dev/uinput cdev
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"