Re: VirtualBOX additions (again)

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

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?

-uwe