Date: Sun, 7 Apr 1996 22:36:03 +0200 From: Thomas Roell <roell@blah.a.isar.de> To: Terry Lambert <terry@lambert.org> Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604072036.WAA00909@blah.a.isar.de> In-Reply-To: <199604072000.NAA00425@phaeton.artisoft.com> References: <199604071839.UAA00701@blah.a.isar.de> <199604072000.NAA00425@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In your message of 7 April 1996 you write: > > Dongle ... good idea. I have to ask our marketing about that ! > > Oh yes, the only thing preventing me from buying it now is an attractive > dongle (note: if you are marketing geek, you may not have recognized > this as sarcasm. It is sarcasm.). Hmmm, although being German I must admit I have a sence of humor, which is more sarcastic than usual. But your notion of an 'attractive Dongle' is really neat. A Dongle as a collectors item. Different colors. Different Designs. Just like the Swatch whatches. Kind of neat idea. Better than the extra vocal track on our next SW-CD, where you'll hear a couple of developers trying to sing ;-) (I shall forgive you this assult of taking me as a market droid) [arguments why select() is still the better way deleted] Just a simple counter example. You have OpenGL, build a cute display list, and kick off rendering with a single X-protocol request. This display list may no take 1 hour to render. Because in that scenario it is not going throu this automata at all you still have the problem with the lost sync of the PS/2 mouse. Granted, that this does make to much sence (who is moving the mosue at all or doing such huge display lists), but we do actually occasionally run into this class of problems. > But your problem is that the automaton is not running at sufficient > granularity to generate a real-time response (which is why using > the pipe() call and selecting on the slave end and writing messages > to yourself that way won't cut it as a fix). I was more thinking about a deamon that had a shared memory segment with the X-Server. This deamon would do the select() on all input devices and actually read data into a buffer. When there is new data read in after the select(), this deamon sends a signal to the X-Server so this buffer can be processed asyncrously. > Is there some reason you can't just increase the buffer in the kernel > to prevent an overflow, if you insist on long delay state processing > of many events without going back out to the top level of the I/O > automaton? Because by default, endusers are not capable of doing that by themselfs. And partly because on some OSes I cannot. The less painful for the end-user I can solve this problem the better it is. > The fix here is to virtualize all mouse I/O in the kernel instead of > presenting seperate abstractions that the X server has to deal with. > > That way, even if you are dumping data on an overflow, you can do so only > on boundries (or you can dynamically start suckung up buffer space to > not lose data at all). Right. This is what SVR4 (except Solaris), SCO and AIX are doing. > One problem (from a casual glance at the driver) seems to be that you > would want to prioritize button events ahead of motion events -- use > a split LRU queue and throw away old consecutive motion events without > an intervening button event to favor button events. This does really not matter. You just package them into neat packets, like SVR4: xq_time timestamp. xq_type XQ_BUTTON, XQ_MOTION, XQ_KEY xq_code button state or scancode xq_x, xq_y mouse position The disadvantage is that if you want to connect also a tablet to the system, you have the keyboard/pointer and the table using two different schemes. One is completely asynchron via a signal, while the other one is using select(). Then you had to resort the time-stamps (which might be invalid for the tablet, since you went throu the whole automata). Very tricky. > Really, a buffer overflow is telling you one of two things: > > a) Your event buffer is too small The problem is not that a couple of events are dropped. The problem really is that part of an event gets dropped, and you cannot resync to get any valid event after that. > b) You are taking too long in your atomaton before getting back > to the state where the buffered events can be processed, and > you need to fix the automaton. Not an option in the general case. There is no way of even predicting how long a single X-Request takes. - Thomas -- Denver Office THOMAS ROELL /\ Das Reh springt hoch, +1(303)298-7478 X INSIDE INC / \/\ das Reh springt weit, 1801 Broadway, Suite 1710 / \ \/\ was soll es tun, Denver, CO 80202 roell@xinside.com / Oelch! \ \ es hat ja Zeit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604072036.WAA00909>