Hello everyone, After talking with some people about the need of proper mouse grabbing for some programs (think about vncv, qwx's quake ports, screenlock), I've implemented it. The devmouse and libdraw patches modify /dev/mousectl to accept two new commands: "clip x0 y0 x1 y1" and "release". The "clip" command confines the mouse inside the given rect. It must be a subrect of the current screen, otherwise the operation will fail. Release undoes that operation (and it's a no-op if there is no grab active). Subsequent clip and release commands override each other, and a grab is automatically released if the fd that made it is closed (in order to prevent a grab to trap the mouse after a program crash). The rio patch modifies rio so that it multiplexes the new grabbing capabilities among its windows. This is transparent to the underlying program: they can clip and release the mouse at will (provided that the clipping rect lies inside their window). Mouse grab in rio follows this rules: - The grab is released after a Reshape event. It's up to the running program to recover that grab in its resize handler. That guarantees the active grab to be always correct (and gives the program a chance to fix it once it isn't anymore) - Only the current window's grab is active at any moment. If some other window is grabbing the mouse, it doesn't have any effect. This keeps rio transparent to the underlying programs grabbing the mouse: they all think they have the global grab at the same time, but focus alone is what ultimately decides which one is active, like it already does for keyboard/mouse input. This proves to be useful when windows are opened while a grab is held (after a plumb, or after spawning a new window). - Rio menus temporarily release the mouse, so options outside of the grabbing rect can be accessed. The grab is restored if needed after the menu is closed. - Windows holding the mouse have a different border color, so they can be clearly identified. Currently it overrides the blue hold color, although I believe that the event of having a text window grabbing the mouse and also holding the input is unlikely. In order to make these changes possible, I had to alter the behavior of rio when handling a reshape done using the window borders: right now it tops the window, and then handles the reshape. I changed that behavior to be the opposite: first handle the resize and then top the window. This allows resizing unfocused windows which would grab the mouse when topped. As far as I know, and after some testing, it looks like I didn't break anything. I'm open to feedback, as there has been interesting alternatives proposed during the development of this patch. I hope that, by bringing my work to the public, any improvements can be shared and reviewed by everyone. Cheers, jmi2k