Around 20 o'clock on Sep 25, Juliusz Chroboczek wrote:
JG So you still have to do a select/poll, read all pending input
JG events on all different devices, and merge the events in the
JG server into a single stream in time stamp order.
Can that happen in dix, or should it be below?
It
Around 20 o'clock on Sep 25, Juliusz Chroboczek wrote:
JG So you still have to do a select/poll, read all pending input
JG events on all different devices, and merge the events in the
JG server into a single stream in time stamp order.
Can that happen in dix, or should it be below?
This is somewhat off topic, but as I recall someone posted a patch to
use the linux event input interface to support hotplugging in xfree86.
it may be of use with what you are looking at now...or not.
Alex
--- Juliusz Chroboczek [EMAIL PROTECTED] wrote:
JG So I'd just open the device and see
Keith Packard wrote:
Yes, it looks like you're correct -- every example I could find would
ensure that pending device input was marked in checkForInput. There are
some odd examples of this however, which are somewhat instructive to
examine:
a) The original A/UX server had
KP a) The original A/UX server had checkForInput marked from the SIGIO
KP handler and read device events in ProcessInputEvents.
Why?
Juliusz
___
Devel mailing list
[EMAIL PROTECTED]
Around 15 o'clock on Sep 24, Juliusz Chroboczek wrote:
KP a) The original A/UX server had checkForInput marked from the SIGIO
KP handler and read device events in ProcessInputEvents.
Why?
There are two goals when dealing with input in the X server:
1) Notice available input
Around 19 o'clock on Sep 24, Juliusz Chroboczek wrote:
Linux 2.[56] does that on the new /dev/event interface (/dev/psaux
would appear to be deprecated). Is it worth using?
Yes. Aside from the improved quality of information available, using
a standard interface for all devices will
JG In fact, the event interface exists in current 2.4; not
JG just 2.[45]. Look in /dev/input/event*.
Some of us still use PS/2 mice...
JG Note that this interface is not just for mice, but is generalized
JG to be usable by pretty arbitrary input devices,
Yes; it looks like all input devices go
Around 1 o'clock on Sep 25, Juliusz Chroboczek wrote:
Some of us still use PS/2 mice...
Nearly all laptops still have the touch pad connected through the PS/2
port, so until the 2.6 driver is backported to 2.4, we'll need PS/2
support in X servers.
Yes; it looks like all input devices go
I use both USB and PS/2. I did play with the event interface
a few hours last year (before my latest encounter with a surgeon),
and convinced myself it seemed to be working correctly with USB.
I think there are patches (that may or may not have been merged
into current 2.4, I don't remember) to
Egbert Eich wrote:
The XKB code could call ProcessInputEvents just above the check for a
pending repeat key; that would ensure that any input queued either in the
X server or the kernel would get processed before repeat status was
checked.
Hm, doesn't ProcessInputEvents() only
Around 21 o'clock on Sep 22, Ivan Pascal wrote:
Also I added a flag for timers TimerNeedsCheckInput. The timers without this
flag are processed before the select all others are delaied until the second
timers check. (The second check doesn't distinguish those timers.)
I think that's
Around 21 o'clock on Sep 23, Ivan Pascal wrote:
c) After devicesReadable is checked
But here I don't understand why this check is needed.
If the select returns some readable devices fd's they all should be read
in Wakeup handlers immediately after the select and this reading should
Hello,
Egbert Eich wrote:
One use for timeouts is to handle external network events, such as font
server reconnect or XDMCP messages. In those cases, the timeout routine
can modify which sockets will be needed in the select mask, hence the
desire for the timeout routine to
I made new version of the patch.
The issue Keith pointed is fixed.
Also I added a flag for timers TimerNeedsCheckInput. The timers without this
flag are processed before the select all others are delaied until the second
timers check. (The second check doesn't distinguish those timers.)
Also
On Mon, Sep 22, 2003 at 09:27:53PM +0700, Ivan Pascal wrote:
I made new version of the patch.
The issue Keith pointed is fixed.
Also I added a flag for timers TimerNeedsCheckInput. The timers without this
flag are processed before the select all others are delaied until the second
timers check.
Keith Packard writes:
Around 20 o'clock on Sep 20, Ivan Pascal wrote:
The solution is obvious. WaitForSomething should not run any callbacks before
the Select but just check timers and if there are expired timers call select
with a zero timeout. Also the code before the select
David,
David Dawes wrote:
On Sun, Sep 21, 2003 at 12:13:10AM -0400, Harold L Hunt II wrote:
The only suggestion I have is that the function prototypes in
include/os.h should follow the conventions of all other prototypes in
os.h, using #if NeedFunctionPrototypes:
extern void
Around 21 o'clock on Sep 21, Egbert Eich wrote:
That was my suggestion. But I'm afraid xkb doesn't work like that.
Not xkb checks for pending input the ddx layer does in a wakeup
handler that does so and passes information on to xkb.
The timeout handling would have to be moved from xkb to
19 matches
Mail list logo
