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? 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.* 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. 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. Jan * 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. > > -- Jirka Z. > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel > _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
