Re: VirtualBOX additions (again)

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

On Wed, 16 Jan 2019 at 00:40, Valery Ushakov <uwe%stderr.spb.ru@localhost> wrote:
>
> 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?

It looks that way, indeed. I haven't processed it quite.

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

It looks rather usable now, anyway. I am not particularly bothered
about the other VirtualBox "niceties" like shared folders, drag and
drop, clipboards etc., as they all can easily enough be replaced with
a simple ssh session from the host. It will be nice if the additions
were made available somewhat easier than now, but is not that hard to
build them from source.

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



-- 
----