On Mon, Apr 22, 2013 at 2:46 PM, Jiří Zárevúcky <[email protected]> wrote: >> 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.
There are no updates that are too old to be useful, the protocol uses relative positioning. By dropping entire event messages you don't desync the protocol but you'll get erratic movement and missed button clicks. What I can not understand is why are you trying to BREAK drivers to match BROKEN device? The mouse driver explicitly requests sample rate to be 120Hz. If the device ACKs that, it should use 120Hz. If it uses more than we can handle it should be disabled. The correct way to handle similar situations would be to disable the auxiliary ps2 port and let the mouse driver reinitialize the device using lower sample rate or different scaling or different resolution. Although I doubt this will work for qemu as it does not throttle the rate to begin with. DEFECTIVE devices are not to be accommodated, they are to be DETECTED and the broken functionality DISABLED. We certainly should not design drivers around broken devices. This is not a quirk to fix different spec interpretation, you are rewriting the stack to handle non-existent pathological situation. Sorry, I can not agree with this approach. Even more so given the fact that the device works OK if it uses the bus it was designed for. Jan _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
