On 12/09/16(Mon) 21:14, Frank Groeneveld wrote: > On Mon, Sep 12, 2016 at 10:18:14AM +0200, Martin Pieuchot wrote: > > > > I just committed your driver, with some tweaks in the manpage. > > Great, thank you! > > > > It is quite likely related to this discussion: > > > > > > http://marc.info/?l=openbsd-misc&m=140529029513846&w=2 > > > http://marc.info/?l=openbsd-misc&m=140589215905202&w=2 > > > http://marc.info/?l=openbsd-misc&m=141676273919602&w=2 > > > > Indeed. This is a common issue to all WSMOUSE_TYPE_TPANEL pointers. > > > > If you're interested in fixing this problem you should look at X11 > > ws(4) driver. If you can modify the driver and the wscons(4) layer > > such that it isn't necessary to open a different node to calibrate > > your device then plugging a device after starting a Xserver wouldn't > > be a problem. > > Thanks for the pointers, that is most probably the cause indeed. I'll > try to dig into this. Is the solution you propose the best one, or would > it also be possible to let the ws driver reopen the device on a failed > read and fix it like that?
Reopening the device is the problem. Because the question is when? If you can have a working solution for your tablet and a standard mouse both using the mux, without sending any even to say "hey a new input device is there, please do something", that would be perfect.