Bryan W. Headley writes:
Egbert Eich wrote:
Bryan W. Headley writes:
As opposed to writing it to a log file. However keep in mind that what
the X client opts to do with any such message(s) is up to that
installation, including logging it to a file. But I'm thinking more
along
Egbert Eich wrote:
Bryan W. Headley writes:
o Packet building. This would be input device/interface type specific.
It would know that a packet of incoming data is 'x' bytes in length; it
might understand that bit 4 is always set for synchronization purposes.
It composes the
Bryan W. Headley writes:
Egbert Eich wrote:
Bryan W. Headley writes:
True, and that's a whole other set of problems. At least, in your
example, everything is in the XI layer, if not in the individual driver.
I'm more worried about an XI layer that talks to its drivers,
Egbert Eich wrote:
Bryan W. Headley writes:
No. I have merged the VIA driver and I did some work on it
to fix some issues that violated the driver design guidelines.
Cool.
2) How is it going?
3) I notice that Via also has L4V and DRM code for X, too. Do you know
if they're putting it into
Egbert Eich wrote:
That just illustrates the problem. Who would think to look at the Misc
extension for that?
I do.
I wouldn't. You could tell me that Misc deals with TrueType fonts and
translucense, and I'd have no reason to disbelieve you, until I looked
at the headers/docs...
The
Bryan W. Headley writes:
Egbert Eich wrote:
A lot of error conditions can only be fixed by the administrator.
Can you come up with a really good real life example?
I suppose 'Battery Low' would be one.
That's the easiest one for everyone to grasp. Let's see: problems with
the
Bryan W. Headley writes:
True, and that's a whole other set of problems. At least, in your
example, everything is in the XI layer, if not in the individual driver.
I'm more worried about an XI layer that talks to its drivers, but
there's also a layer in Misc that does the same thing,
Egbert Eich wrote:
OT for a second... I've read somewhere that the Xv layer has problems
with the VIA CLE266 driver, and that you were working on it.
1) True? (Did you know you were working on it, or is this someone's
mistaken impression?)
2) How is it going?
3) I notice that Via also has L4V
Egbert Eich wrote:
Bryan W. Headley writes:
True, and that's a whole other set of problems. At least, in your
example, everything is in the XI layer, if not in the individual driver.
I'm more worried about an XI layer that talks to its drivers, but
there's also a layer in Misc that
Egbert Eich wrote:
Bryan W. Headley writes:
Egbert Eich wrote:
A lot of error conditions can only be fixed by the administrator.
Can you come up with a really good real life example?
I suppose 'Battery Low' would be one.
That's the easiest one for everyone to grasp. Let's see:
Egbert Eich wrote:
Bryan W. Headley writes:
Egbert Eich wrote:
As you said a HID device is more or less unidirectional. Therefore
you won't be able to detect from the device interface that something
is wrong. The HID interface itself would have to provide QoS.
Anyway QoS would
Egbert Eich wrote:
Bryan W. Headley writes:
I do understand the 'the battery in the cordless mouse is getting low'
message. This would better live in the hardware messaging, ie. the
successor of todays xf86misc extension.
Ah! You're concerned about which layer supports the messaging. I'm not
as
Egbert Eich wrote:
I dropped Jim Gettys a note, asking him about his involvement with
XInput. If he's not working on it anymore, maybe he can pass some of his
ideas and we can incorporate that. And if he is, great. The more the
merrier.
Right.
No reply from Jim yet. Either he's not
Bryan W. Headley writes:
Egbert Eich wrote:
Bryan W. Headley writes:
Egbert Eich wrote:
As you said a HID device is more or less unidirectional. Therefore
you won't be able to detect from the device interface that something
is wrong. The HID interface
Joe Krahn wrote:
I agree that device messages should all be in one place. There are
messages to and from the user, as well as to and from the device.
Hope I wasn't dancing on anyone's toes
So, if all of this will be an XINPUT expansion, this discussion
would be better off in the little-used
Egbert Eich wrote:
A lot of error conditions can only be fixed by the administrator.
Can you come up with a really good real life example?
I suppose 'Battery Low' would be one.
That's the easiest one for everyone to grasp. Let's see: problems with
the input device (it didn't accept
Egbert Eich wrote:
Bryan W. Headley writes:
Egbert Eich wrote:
Bryan W. Headley writes:
I do understand the 'the battery in the cordless mouse is getting low'
message. This would better live in the hardware messaging, ie. the
successor of todays xf86misc extension.
Ah! You're
Egbert Eich wrote:
As you said a HID device is more or less unidirectional. Therefore
you won't be able to detect from the device interface that something
is wrong. The HID interface itself would have to provide QoS.
Anyway QoS would not be part of XI but would be implemented in the
HW messaging
Egbert Eich wrote:
Bryan W. Headley writes:
Maybe not everything... Some things only make sense at server startup,
but yes, I want to make things configurable on the fly - but using
another extension, not XI.
Correct. My outlook is a more generic client -- driver API
Bryan W. Headley writes:
Egbert Eich wrote:
Your definition and mine are very similar. I would continue the
definition to say that even intrinsic server functions, like loading a
driver into memory, can be initiated by a client. Why? Because I would
want to keep the actual server
Bryan W. Headley writes:
Egbert Eich wrote:
As you said a HID device is more or less unidirectional. Therefore
you won't be able to detect from the device interface that something
is wrong. The HID interface itself would have to provide QoS.
Anyway QoS would not be part of XI
Mike A. Harris writes:
Doesn't the following CVS commits implement such an API?
Yes, although I don't like the implementation. It requires that the
client knows the exact details of a particular driver. This should be
replaced by something that provides more information on the
Bryan W. Headley writes:
Maybe not everything... Some things only make sense at server startup,
but yes, I want to make things configurable on the fly - but using
another extension, not XI.
Correct. My outlook is a more generic client -- driver API (remember I
use the word
Bryan W. Headley writes:
Sorry, just telling you how it is, now. hotplug listens to a kernel
message layer, and invokes shell scripts in response to events. These
scripts can load/unload kernel device drivers, mount discs, etc. All
these things would do is write a message to some kind
Bryan W. Headley writes:
David Dawes wrote:
On Fri, Aug 29, 2003 at 02:28:13PM -0400, Joe Krahn wrote:
I've discussed XINPUT before, tried to fix some things, and
realized that the XFree86 XINPUT code needs a complete re-write.
It is particularly messed up for non-pointer devices.
Rafa³ Rzepecki writes:
On Thursday 28 of August 2003 17:59, Egbert Eich wrote:
Sure. What we should probably do now is to get in touch with all
interested parties to get their input. We must make sure we don't
jump too short again.
A generalized API for passing messages to and from
Claus Matthiesen writes:
Actually, I'm really getting into the idea that the device can sort of
tell the application how to interpret its data. I'll elaborate later in
the mail...
OK.
You may want to 'bind' one tablet to one application and the other one
to another appication.
Bryan W. Headley writes:
Egbert Eich wrote:
Claus Matthiesen writes:
Let's just forget about expanding the _XDeviceInfo struct for a minute
and just concentrate on the -type field. Because as regards legacy
software: Does anybody use the -type field? I don't want to
Egbert Eich wrote:
Claus Matthiesen writes:
I may have been imprecise. You can register a pen that hasn't been
seen before by bringing it close to the tablet so that the tablet
detects it. You cannot remove a pen once it is moved out of the
proximity of the tablet. Only if the tablet itself is
Egbert Eich wrote:
Bryan W. Headley writes:
Egbert Eich wrote:
Claus Matthiesen writes:
Let's just forget about expanding the _XDeviceInfo struct for a minute
and just concentrate on the -type field. Because as regards legacy
software: Does anybody use the -type field? I
Egbert Eich wrote:
Few drivers do such things now, but using weird tricks (vide XLedFeedback in
citron or shared memory in synaptics).
Yes, many of those 'tricks' may actually introduce security holes.
You bet they do!
But I also agree that a user should be able to ask his stylus it's
Mike A. Harris wrote:
On Sun, 31 Aug 2003, Egbert Eich wrote:
On Thursday 28 of August 2003 17:59, Egbert Eich wrote:
Sure. What we should probably do now is to get in touch with all
interested parties to get their input. We must make sure we don't
jump too short again.
A generalized API for
In the very early days of [EMAIL PROTECTED] Sven Luther and I
discussed something like this. Eventually this discussion faded
out in the heat of these days
Doesn't the following CVS commits implement such an API?
No, but it is the beginning of one. Right now, you cannot specify the
Bryan W. Headley wrote:
No but you don't want to be a jerk and compete with somebody else. As
if there were enough developers to go around that we'd steal each
other's projects :-)
Sometimes a little competition can improve the final product. Think lvm2 v.
evms in the early 2.5 kernels.
Warren Turkal wrote:
Bryan W. Headley wrote:
No but you don't want to be a jerk and compete with somebody else. As
if there were enough developers to go around that we'd steal each
other's projects :-)
Sometimes a little competition can improve the final product. Think lvm2 v.
evms in the
I've discussed XINPUT before, tried to fix some things, and
realized that the XFree86 XINPUT code needs a complete re-write.
It is particularly messed up for non-pointer devices. Jim
Gettys took over XFree86 XINPUT, and agreed that a re-write
is needed. I put off working on XINPUT until he got
--- Bryan W. Headley [EMAIL PROTECTED] a
écrit : Egbert Eich wrote:
Bryan W. Headley writes:
snip
Sorry, just telling you how it is, now. hotplug
listens to a kernel
message layer, and invokes shell scripts in response
to events. These
scripts can load/unload kernel device drivers,
On Fri, Aug 29, 2003 at 02:28:13PM -0400, Joe Krahn wrote:
I've discussed XINPUT before, tried to fix some things, and
realized that the XFree86 XINPUT code needs a complete re-write.
It is particularly messed up for non-pointer devices. Jim
Gettys took over XFree86 XINPUT, and agreed that a
Claus Matthiesen writes:
Exactly. Sort of guessing on the basis of a string which might contain this
or that isn't good enough for industrial strength software which we all
agree should be able to run under Linux/XFree. But unless I am much
mistaken, there is *no other* way of finding
Claus Matthiesen writes:
Let's just forget about expanding the _XDeviceInfo struct for a minute
and just concentrate on the -type field. Because as regards legacy
software: Does anybody use the -type field? I don't want to change the
-name, that's fine as it is and that's what most
Egbert Eich wrote:
Let me finish by saying that even though I have never had my hands deep in
the code of X, of course I'd be happy to help out - if doing a little coding
in X makes my port of the toolkit go smoother it's definetely worth the
effort. All I need to have is a consensus on
Egbert Eich wrote:
Claus Matthiesen writes:
Let's just forget about expanding the _XDeviceInfo struct for a minute
and just concentrate on the -type field. Because as regards legacy
software: Does anybody use the -type field? I don't want to change the
-name, that's fine as it is and
On Thu, 2003-08-28 at 17:59, Egbert Eich wrote:
Claus Matthiesen writes:
Exactly. Sort of guessing on the basis of a string which might contain this
or that isn't good enough for industrial strength software which we all
agree should be able to run under Linux/XFree. But unless I am
- Original Message -
From: Bryan W. Headley [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 26, 2003 9:43 PM
Subject: Re: XInput: The device type in XListInputDevices comes up again...
Cut a bit of code
The problem is, there's a type field and a name field. They're
Bryan W. Headley writes:
Egbert Eich wrote:
That is correct. However Claus was talking about the future - once
that is fixed. Appearantly toolkits like gnome already do make use
of the name field.
Sure, albeit dangerously. They had best not be making decisions based on
what's
Claus Matthiesen wrote:
- Original Message -
From: Bryan W. Headley [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 26, 2003 9:43 PM
Subject: Re: XInput: The device type in XListInputDevices comes up again...
Cut a bit of code
The problem is, there's a type field and a name
:
- Original Message -
From: Bryan W. Headley [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 26, 2003 9:43 PM
Subject: Re: XInput: The device type in XListInputDevices comes up again...
Cut a bit of code
The problem is, there's a type field and a name field
Claus Matthiesen wrote:
Weee! Device interface designing is fun!
As a side note - isn't it rater a failure of the extended input thingy
in X when neither the application programmer nor the device driver
programmer think it's good enough?
La la la la. I can't read you :-)
--
On Wed, 2003-08-27 at 19:52, Bryan W. Headley wrote:
Claus Matthiesen wrote:
Weee! Device interface designing is fun!
As a side note - isn't it rater a failure of the extended input thingy
in X when neither the application programmer nor the device driver
programmer think it's good
First of all: Since I am new to this list (this is my first post), I do
hope that I'll be able to avoid the major pitfalls of what is considered
bad behaviour on this particular mailing list... :-)
Since I am currently writing a device manager for a cross-platform
windowing toolkit under OpenGL
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the
Bryan W. Headley writes:
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have
Egbert Eich wrote:
Bryan W. Headley writes:
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
53 matches
Mail list logo
