Re: VirtualBOX additions (again)

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

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.

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



-- 
----