On 22 April 2013 11:52, Ján Veselý <[email protected]> wrote: > On Mon, Apr 22, 2013 at 2:27 AM, Jiří Zárevúcky > <[email protected]> wrote: >> FYI, I managed to make the mouse actually usable and safe(r) to use, >> without changing the notification handling mechanism. >> To do so, I extended the CHARDEV protocol to allow reading large >> payloads through data_read (a useful thing in any case, since >> character devices are streams that can easily be buffered), and >> changed the buffers in i8042 to a larger size (a few kilobytes to be >> on the safe side). >> ps2mouse then simply reads a large buffer in one call and combines all >> the moves into a single message, instead of one message per move >> packet (other packets are processed as usual). These changes make it >> fast enough to deal even with my fast mouse and slow emulation. >> >> Note that the CHARDEV extension is really a big hack and ps2mouse >> changes are not complete (or nicely coded), so the attached diff is >> for illustration only, not for merging. Any suggestions on how to make >> this mergeable (especially the protocol part) are welcome. > > you did several separate things in that patch; > > a) you disabled intellimouse extensions, this alone reduces irq rate > by 25%, are you sure it's not the impact of this reduction that you > see? >
This change alone doesn't change the behavior at all. That was the first thing I checked. > b) you increased buffer size few hundred times, what is the effect of > this change alone (or combined with a)? I think you can even drop data > if the buffer is full. It will replace the implicit fibril list with > buffer fifo (yes I changed my mind and agree that this would not be > much different to dropping data when we fail to create handler > fibril). It will also serve as safety measure in case ps2mouse driver > dies or stops reading data from the buffer.* > This alone justs slows down the degradation. The rest of the stack is still unable to process moves in real time, though, so the mouse will move at a constant slow speed while catching up with quickly growing buffer. Not usable at all. Incidentally, having a whole buffer to read at once allows the ps2mouse driver to change operation mode to explicit polling when it detects that the buffer grows too much. That is the next thing I would like to do. > c) you changed the chardev to read variable amount of data in one > request. I really don't see the benefit of this especially if the > ps2mouse driver sends out one message per event. This is the one thing that actually fixes the problem. Instead of propagating outdated information all the way through the pipeline, ps2mouse is able to clear all outdated moves in one update. Note that even if you have fast machine, the load can still cause the buffer to grow. > How does one message > turns from a "lousy implementation" when reading packets to something > that is OK when sending events? IMO using one ipc rt for something > that is _hardware limited_ to <=200Hz is OK. > Any interrupt storm only affects the i8042 driver, and ps2mouse is able to clear it out fast enough when it does not need to resend updates it *knows* are already too old to be useful. > > * If we disable the buffer (no more writes) after the first drop, we > can send this information to the mouse driver (when it tries to read > empty disabled buffer) and let it reinitialize the device and then > re-enable the buffer. > Switching the mode of operation when the buffer grows over a fixed threshold seems like a more practical thing to me. -- Jirka Z. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
