>> In particular, I note that [the "broken" boot attaches devices in a
>> different order from the "working" boot]
> This is not it. [...]
This morning I finally tracked this down. It was something entirely
unexpected, at least to me.
I had somehow (a) failed to install /dev/wsmouse when
> [W]hat if you work in the opposite direction? That is, after
> everything is booted and working, never mind the magic that makes it
> go, you explicitly detach the mouse from the wsmux it picks by
> default and explicitly reattach it to the mux you want before
> starting your application?
Ah,
> [W]hat if [...], after everything is booted and working, never mind
> the magic that makes it go, you explicitly detach the mouse from the
> wsmux it picks by default and explicitly reattach it to the mux you
> want before starting your application?
> [...wsmuxctl...]
Ooh! I had somehow
hello. Following up on your observations, what if you work in the
opposite direction?
That is, after everything is booted and working, never mind the magic that
makes it go, you
explicitly detach the mouse from the wsmux it picks by default and explicitly
reattach it to
the mux you
I wrote
> In particular, I note that [the "broken" boot attaches devices in a
> different order from the "working" boot]
This is not it. I took the kernel config I use for the development
machine (where it works), changed only one thing
--- aaeon-9:kconf/GEN91 Mon Dec 28 22:06:05 2020
+++
Back on 2021-02-23, I wrote of issues getting mouse events via wsmux on
a turnkey product built on 9.1/amd64.
Besides Brian Buhrow's helpful remarks on the list, one person sent
mail off-list quoting my
> The only thing I can think of is the time delay between the X server
> starting and the
> If I had to wager a guess as to what's going on, I'd say that when
> you start the system, the wsmouse0 gets attached to wsmux2 when the
> system comes up, but by the time you unplug the mouse and plug it in
> again, your application has the /dev/wsmouse0 device open, [...]
The application
hello. I think a clue lies in a snippet of the wsmux(4) man page:
If a wskbd(4), wsbell(4), or wsmouse(4) device is opened despite having a
mux it will be detached from the mux.
If I had to wager a guess as to what's going on, I'd say that when you
start the system,
> How are you forcing the mouse to use mux 2? [...]
Custom kernel, with "mux 2" specified on the relevant attachment lines.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39
hello. Silly question. How are you forcing the mouse to use mux 2?
Is it a custom
kernel, a sysctl variable, an unused mouse plugged into the machine elsewhere?
-thanks
-Brian
I'm working on a turnkey product under 9.1. Among other things, it
uses X for output and for keyboard input, but reads mouse input events
semi-directly (mostly because it wants deltas, whereas X insists on
integrating deltas into absolute locations, then clipping those
locations to the screen
11 matches
Mail list logo
