Re: VirtualBOX additions (again)

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Tue, Jan 15, 2019 at 23:25:16 +0000, Chavdar Ivanov wrote:

> One more observation, essentially almost resolving the problem. It
> works fine with only the touchpad, as long as one slides one's finger
> after clicking, any direction. Its the static click which does not
> register with [c]twm. With an external mouse it seems to work
> properly.

Are you describing what I've written a few mails upthread, though
perhaps not very clearly?

> > > 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


Also, thanks for testing, I'll try to dig more later this week as time
permits.



> On Tue, 15 Jan 2019 at 20:10, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
> >
> > 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