Re: Wayland work status

[Lundberg, Johannes]

Thanks for the help Matthew..
Yeah, I can't believe it was working all along and a stupid copy/paste
error gave us so much trouble...

On Sat, Aug 13, 2016 at 12:26 AM, Matthew Macy  wrote:

>
>  >
>  > ​Wayland relies on kqueue which is not implemented in drm's 3.8 or 4.6
>  > branches. I'm working on this now for drm-next-4.6 and it is almost
>  > complete.
>  > I will probably implement it also in the 3.8 ​branch to be able to run
>  > Wayland on both to compare and find bugs in linuxkpi more easily. Will
>  > share patch for 3.8 branch when done.
>  >
>
> drm-next has working kevent support following shortly after the drm-v4.7
> tag. Your kqfilter implementation would be ideal for 3.8 but is not
> suitable for drm-next as it substantially modifies vendor code. I think
> your implementation does in fact work or is very close. Your apparent
> problem stemmed from an index overwrite in your modified kmscube.c test
> case.
>
> A working kmscube.c can be found at:
>
> https://github.com/FreeBSDDesktop/kmscube
>
> With no arguments it will use select. If you pass -k it will use kevent.
> -M
>
>

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wayland work status

[Matthew Macy]

 > 
 > ​Wayland relies on kqueue which is not implemented in drm's 3.8 or 4.6
 > branches. I'm working on this now for drm-next-4.6 and it is almost
 > complete.
 > I will probably implement it also in the 3.8 ​branch to be able to run
 > Wayland on both to compare and find bugs in linuxkpi more easily. Will
 > share patch for 3.8 branch when done.
 > 

drm-next has working kevent support following shortly after the drm-v4.7 tag. 
Your kqfilter implementation would be ideal for 3.8 but is not suitable for 
drm-next as it substantially modifies vendor code. I think your implementation 
does in fact work or is very close. Your apparent problem stemmed from an index 
overwrite in your modified kmscube.c test case.

A working kmscube.c can be found at:

https://github.com/FreeBSDDesktop/kmscube

With no arguments it will use select. If you pass -k it will use kevent.
-M

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wayland work status

[Lundberg, Johannes]

Hi

I followed the instructions for evdev enabled kernel here
https://github.com/wulf7/libudev-devd and it works fine!
I needed to update libinput to latest version since it was required by
xf86-input-libinput so I'm using latest version from
https://github.com/jiixyj/libinput.

As for the wsp driver I've simply added REL_HWHEEL to get x/y scrolling and
changed the back/forward events to x axis scrolling. See the attached
patch.  It's still really simple but adds a bit more functionality compared
to what is allowed by the old mouse protocol. Of course, if you want
advanced multi-touch gestures, it's need to be rewritten a lot. Although, I
don't know how many X apps actually support this so maybe it's a lot of
work for nothing...

I also needed to change the order of horizontal scroll wheel and buttons
with
xinput set-button-map 6  3 2 1 4 5 7 6 ​

​I think wsp already puts out vertical scroll in opposite direction by
default. ​

​I'm using xfce4 as desktop environment.​


On Fri, Aug 12, 2016 at 1:12 PM, Jan Kokemüller 
wrote:

> Hi,
>
> On 12.08.16 19:22, Lundberg, Johannes wrote:
>
>> ​Where can I find xf86-input-libinput for FreeBSD? Will the original
>> source build?
>>
>
> Yes, the original source (https://cgit.freedesktop.org/
> xorg/driver/xf86-input-libinput/) will build unmodified.
>
> I've copied libinput_drv.so to 
> /usr/local/lib/xorg/modules/input/libinput_drv.so
> and installed "99-libinput.conf" into /usr/local/etc/X11/xorg.conf.d so
> that X will use libinput for the /dev/input/event* devices by default and
> not xf86-input-evdev or -synaptics.
>
> Libinput has pretty advanced multitouch scrolling and gesture support that
> relies on evdev multitouch packets (https://www.kernel.org/doc/Do
> cumentation/input/multi-touch-protocol.txt). Are you already sending
> these packets, or are you sending relative (EV_REL) packets? Looking at the
> wmt driver in the wulf7/evdev branch sending EV_ABS packets does not seem
> too hard for USB based touchpads.
>
> It is probably easiest to boot Linux, dump all evdev packets from the
> touchpad with the libevdev-events tool from libevdev, and then try to
> emulate that output with the wsp driver.
>
> For testing smooth scrolling, gtk3-demo is pretty good; or recent versions
> of Firefox with the MOZ_USE_XINPUT2 environment variable set to 1.
>
> -Jan
>

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
diff --git a/sys/dev/usb/input/wsp.c b/sys/dev/usb/input/wsp.c
index 694e0d9..21cc518 100644
--- a/sys/dev/usb/input/wsp.c
+++ b/sys/dev/usb/input/wsp.c
@@ -27,6 +27,8 @@
 #include 
 __FBSDID("$FreeBSD$");
 
+#include "opt_evdev.h"
+
 #include 
 #include 
 #include 
@@ -54,6 +56,11 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
+#ifdef EVDEV
+#include 
+#include 
+#endif
+
 #defineWSP_DRIVER_NAME "wsp"
 #defineWSP_BUFFER_MAX  1024
 
@@ -83,6 +90,7 @@ SYSCTL_INT(_hw_usb_wsp, OID_AUTO, debug, CTLFLAG_RWTUN,
 static struct wsp_tuning {
int scale_factor;
int z_factor;
+   int t_factor;
int pressure_touch_threshold;
int pressure_untouch_threshold;
int pressure_tap_threshold;
@@ -92,6 +100,7 @@ static struct wsp_tuning {
 {
.scale_factor = 12,
.z_factor = 5,
+   .t_factor = 5,
.pressure_touch_threshold = 50,
.pressure_untouch_threshold = 10,
.pressure_tap_threshold = 120,
@@ -113,6 +122,8 @@ SYSCTL_INT(_hw_usb_wsp, OID_AUTO, scale_factor, 
CTLFLAG_RWTUN,
 _tuning.scale_factor, 0, "movement scale factor");
 SYSCTL_INT(_hw_usb_wsp, OID_AUTO, z_factor, CTLFLAG_RWTUN,
 _tuning.z_factor, 0, "Z-axis scale factor");
+SYSCTL_INT(_hw_usb_wsp, OID_AUTO, t_factor, CTLFLAG_RWTUN,
+_tuning.t_factor, 0, "T-axis scale factor");
 SYSCTL_INT(_hw_usb_wsp, OID_AUTO, pressure_touch_threshold, CTLFLAG_RWTUN,
 _tuning.pressure_touch_threshold, 0, "touch pressure threshold");
 SYSCTL_INT(_hw_usb_wsp, OID_AUTO, pressure_untouch_threshold, CTLFLAG_RWTUN,
@@ -541,7 +552,12 @@ struct wsp_softc {
u_int   sc_pollrate;
mousestatus_t sc_status;
u_int   sc_state;
+   u_int   sc_fflags;
 #defineWSP_ENABLED0x01
+#ifdef EVDEV
+   int sc_evflags;
+#defineWSP_EVDEV_OPENED1
+#endif
 
struct tp_finger *index[MAX_FINGERS];   /* finger index data */
int16_t pos_x[MAX_FINGERS]; /* position array */
@@ -559,9 +575,12 @@ struct wsp_softc {
int 

Re: Wayland work status

[Jan Kokemüller]

Hi,

On 12.08.16 19:22, Lundberg, Johannes wrote:

​Where can I find xf86-input-libinput for FreeBSD? Will the original
source build?


Yes, the original source 
(https://cgit.freedesktop.org/xorg/driver/xf86-input-libinput/) will 
build unmodified.


I've copied libinput_drv.so to 
/usr/local/lib/xorg/modules/input/libinput_drv.so and installed 
"99-libinput.conf" into /usr/local/etc/X11/xorg.conf.d so that X will 
use libinput for the /dev/input/event* devices by default and not 
xf86-input-evdev or -synaptics.


Libinput has pretty advanced multitouch scrolling and gesture support 
that relies on evdev multitouch packets 
(https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt). 
Are you already sending these packets, or are you sending relative 
(EV_REL) packets? Looking at the wmt driver in the wulf7/evdev branch 
sending EV_ABS packets does not seem too hard for USB based touchpads.


It is probably easiest to boot Linux, dump all evdev packets from the 
touchpad with the libevdev-events tool from libevdev, and then try to 
emulate that output with the wsp driver.


For testing smooth scrolling, gtk3-demo is pretty good; or recent 
versions of Firefox with the MOZ_USE_XINPUT2 environment variable set to 1.


-Jan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wayland work status

[Lundberg, Johannes]

>
> If you feel adventurous, you can try out the current state of the libinput
> port here (1.4.0):
> https://github.com/jiixyj/libinput
>
>
​Great! Will check it out.
​


> I haven't yet tested the port with the evdev kernel work, though. I've
> been using my evdev implementation in userspace which uses cuse to create
> /dev/input/event* devices (https://github.com/jiixyj/evdevfbsd). I needed
> to adjust a few ioctl defines from the linux/input.h header to make some
> features work. The way Linux defines EVIOCGMTSLOTS and EVIOCGRAB didn't
> work with cuse. The kernel evdev implementation may work slightly
> differently, so that's something to look out for.
>
>
​Kernel evdev implementation seems to work great. It is fairly easy to add
evdev functionality to existing drivers. I just patched the wsp (for
Macbook's touchpad) driver to add it to evdev. I modified it a bit to add
two finger x-y scroll like on macOS. I can't wait to try it on X so I'm
gonna try get libinput working with X today.
​


> I've moved the udev-stubs.{c,h} out of the port into a separate library,
> but libudev-devd (https://github.com/wulf7/libudev-devd) certainly looks
> more mature!
>
>
​I couldn't get it working with your udev-stubs and I found libudev-devd
which seemed to be more mature. It works great so far!​


> All this can be used with the xf86-input-libinput driver to get smooth and
> horizontal scrolling in X, which is awesome!
>

​Where can I find xf86-input-libinput for FreeBSD? Will the original source
build?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wayland work status

[Lundberg, Johannes]

> There is a similar problem for the drm devices (by default, users can’t
> use 3D acceleration).  A devfs.conf policy can change the permissions.  I’d
> suggest that we create a default group called something like console or
> local, put new users there by default, and make drm and evdev devices
> accessible by this group.
>
> David
>
>

​Actually in Linux wlc and I think also Weston recommend using setuid for
the compositor. It then forks and drops permission. All devices are opened
as superuser and then sent to the child process. This works fine for me
with tty and drm, however, libinput complains about devices not being
tagged as input device but they are opened successfully. I haven't looked
deeper into why...

As for X11, maybe this approach does not work and we need group permissions.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wayland work status

[Jan Kokemüller]

Hi,

On 12.08.16 01:18, Lundberg, Johannes wrote:

x11/libinput (removed udev-stubs and linked to libudev-devd)


If you feel adventurous, you can try out the current state of the 
libinput port here (1.4.0):

https://github.com/jiixyj/libinput

I haven't yet tested the port with the evdev kernel work, though. I've 
been using my evdev implementation in userspace which uses cuse to 
create /dev/input/event* devices (https://github.com/jiixyj/evdevfbsd). 
I needed to adjust a few ioctl defines from the linux/input.h header to 
make some features work. The way Linux defines EVIOCGMTSLOTS and 
EVIOCGRAB didn't work with cuse. The kernel evdev implementation may 
work slightly differently, so that's something to look out for.


I've moved the udev-stubs.{c,h} out of the port into a separate library, 
but libudev-devd (https://github.com/wulf7/libudev-devd) certainly looks 
more mature!


The libinput code itself isn't that different from upstream anymore. 
I've removed the epoll->kqueue porting work and written a small epoll 
wrapper instead that implements everything libinput/libevdev and 
possibly wayland needs (https://github.com/jiixyj/epoll-shim). This 
isn't integrated yet into the build system of the libinput port, though. 
So you have to do something like 'CFLAGS="-I ~/git/epoll-shim/include -L 
~/git/epoll-shim -lepoll-shim -pthread" LDFLAGS="-pthread -lrt"' when 
configuring libinput.


All this can be used with the xf86-input-libinput driver to get smooth 
and horizontal scrolling in X, which is awesome!


--
Jan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wayland work status

[David Chisnall]

On 12 Aug 2016, at 00:18, Lundberg, Johannes  
wrote:
> 
> Currently by default evdev create /dev/input/eventX devices with 600
> permission. These need to be accessible for non-root users. What is the
> best solution? Should we create a "input" group similar to "video" group is
> being used for rights to access /dev/drm devices?

There is a similar problem for the drm devices (by default, users can’t use 3D 
acceleration).  A devfs.conf policy can change the permissions.  I’d suggest 
that we create a default group called something like console or local, put new 
users there by default, and make drm and evdev devices accessible by this group.

David



smime.p7s
Description: S/MIME cryptographic signature