Date: Sun, 7 Apr 1996 14:32:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: roell@blah.a.isar.de (Thomas Roell) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604072132.OAA00676@phaeton.artisoft.com> In-Reply-To: <199604072036.WAA00909@blah.a.isar.de> from "Thomas Roell" at Apr 7, 96 10:36:03 pm
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 want royalties if you go all the way with this -- like Japanese collector "phone cards" with favorite Anime for the Otaku (fans) to buy. I'd probably buy a "Uresai Yatsura" (Those Obnoxious Aliens) dongle just to have one. 8-). > [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. I'd probably argue that if it isn't going through the automata at all, then the implementation is probably broken in terms of allowable concurrency. Nevertheless, see my other resonse where I suggested pthreads. The problem is, of course, that you can't process things in zero time, and the question is whether to eat the meta-overhead of increasing the automaton's complexity. You'll do this with the suggestion I made previously about unwinding the main loop through the I/O processor, and you'll do the same thing with a threading environment. Which is better (if either is better) is a matter for you to decide based on relative amount of events in both device and client subautomatons. > > 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. You can do the same thing without needing another process if you popen a fipe and write events to yourself that can then be selected upon. THis might very well fix your buffering id 1K vs. 6k (5k pipe + 1k kernel) is enough to fix the problem for you. > > 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. Well. It seems that you really want a fix in another area of BSD, and that this fix is just a software fix to the fact that the other area is broken. 8-). > > 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. Not a problem, if you virtualize all pointing devices the same way, at the kernel->useer interface level. It should be done that way to avoid user-space polling for some hardware (busmouse) anyway. Again, a BSD fix is needed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604072132.OAA00676>