Re: VirtualBOX additions (again)

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On Tue, 15 Jan 2019 at 17:16, Valery Ushakov <uwe%stderr.spb.ru@localhost> wrote:
>
> On Sun, Jan 13, 2019 at 05:17:42 +0300, Valery Ushakov wrote:
>
> > On Sat, Jan 12, 2019 at 20:36:58 +0000, Chavdar Ivanov wrote:
> >
> > > Actually, resizing with ctwm works just fine, even the delay seems to
> > > be not more than a couple of seconds. What is not working for me is
> > > the screen menus for [c]twm. They work fine with xfce4 and lxde
> > > though, so its not like the event is not recognized. Strange.
> >
> > I've just noticed this accidentally. It seems that sometimes X does
> > not deliver a button press event when it happens and only delivers it
> > when there's the next event to deliver.  If you use a real mouse (the
> > one you actually drag) it's easy to miss this problem b/c a slight
> > twitch of hand will cause the motion event to kick the button press
> > event delivery.  But if you use say trackpad buttons, the button press
> > will only get delivered along with the button release event.  You can
> > use xev(1) to see that and also to verify that twm *does* show you the
> > menu (on the press) only to immediately hide it on release (that
> > caused the press to be delivered).  Just click on the root a bit above
> > the xev window and you'll see visibility and expose events caused by
> > the menu.
> >
> > Also it magically auto-heals sometimes, though I don't know what
> > causes it to auto-heal.  You can try scientific method and just wildly
> > move your mouse around, mashing mouse buttons and keybaord keys.
> > Voila!  Press events start to come when the mouse is actually pressed.
> >
> > Note that
> >
> >   # hexdump -C /dev/wsmouse
> >
> > always show the events immediately.
> >
> > Selecting either PS/2 or USB tablet (which is preferred since it can
> > deliver absolute position events) for a pointing device doesn't seem
> > to affect this, though I didn't do rigorous testing.
> >
> > Also note that the device setup is a bit funky.  There's "real"
> > (emulated) mouse device (wsmouse0 at pms0 or wsmouse1 at ums0, etc)
> > and there's guest additions mouse device (wsmouse2 at vboxguest0).  If
> > the GA device is opened (either directly or via /dev/wsmouse mux) it
> > delivers only the positional events, the button events will still be
> > delivered via the real (emulated) mouse.  You can see that hexdumping
> > the GA wsmouse device will only show you positional events.
> >
> > So may be there is a VBox bug in the mouse emulation that doesn't
> > deliver presses (to wsmouse0) b/c reasons...  But then dumping the mux
> > (i.e. like X server would see it) seems to show the presses
> > immediately.
>
> Just a few quick observations.
>
> Running ktruss -p $x fixes event delivery BUT only while ktruss is
> running.  When you kill it, the menus are inaccessible again.
>
>   # (STDBUF1=L ktruss -p $x) | grep --line-buffered 'read.*0xd,.* = '
>
> here 0xd is fd 13 which is wsmux0 (aka wsmouse).  I think it's always
> the same fd, but fstat -p $x | grep wsmux0 will tell you for sure.
>
> Running ktrace -p $x does not affect the problem.
>
> Middle click fixes the problem.
>
>
> Can you confirm whether you are also seeing this?

Yes, I can. It behaves exactly as you say. I just connected for a
moment a mouse to my W10 laptop, middle click registered OK, after
that left click also worked, and continued to work with the touchpad
after I disconnected the mouse.

>
> -uwe

Chavdar


-- 
----