Re: Emulate3Buttons support for X68k Xorg server

[christos%astron.com@localhost (Christos Zoulas)]

In article <210206112947.M0107944%mirage.ceres.dti.ne.jp@localhost>,
Izumi Tsutsui  <tsutsui%ceres.dti.ne.jp@localhost> wrote:
>christos@ wrote:
>
>> >The patch is attached and also in the following gist
>> >(applicable both to HEAD and netbsd-9):
>> > https://gist.github.com/tsutsui/6ebe82d74b11874b92b167769c312d52
>> >
>> >Note the original xf86-input-mouse driver's Emulate3Buttons
>> >implementation is here:
>> >
>https://gitlab.freedesktop.org/xorg/driver/xf86-input-mouse/-/blob/xf86-input-mouse-1.9.3/src/mouse.c#L1876
>> >
>> >Comments?
>> 
>> I am fine with it, but are you planning to upstream the emulate three buttons
>> patch to Xorg?
>
>Currently no.
>
>The monolithic X68k server in xorg-server/dist/hw/netbsd/x68k
>(and Xsun servers in xorg-server/dist/hw/sun) are our own porting
>(by me) and I doubt upstream will import such monolithic Xserver
>implementation for NetBSD specific Tier-II machines.
>
>The Emulate3Buttons support is handled by the xf86-input-mouse
>driver for the mainstream Xorg modular server. The driver supports
>various mouse devices (including Linux evdev) so it looks there is
>less motivation to refactor the Emulate3Buttons part as a module.
>
>The "rewriting a magic three-dimensional array for a finate state
>machine with proper named structures etc." part might be useful
>even for the current xf86-input-mouse driver. But I wonder if
>"no functional changes but just for readability for support of
>rare mice without wheel buttons derived from ancient XFree86" is
>worth for the upstream.
>
>The upstream still has several monolithic servers like xquartz etc.
>But currently only xorg-server/dist/hw/xwin has implementation for
>3 button emulation and it uses a different (and maybe a bit incomplete)
>implementation from xf86-input-mouse:
> https://gitlab.freedesktop.org/xorg/xserver/-/blob/xorg-server-1.20.9/hw/xwin/winmouse.c#L258

Thanks for the explanation. I think it would be good to make upstream aware
of the better code and let them choose how to handle it :-)

christos