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 separate from these ancilliary functions.
This is not how an X client works. X abstracts all these details from
the client. The client should not have to deal with HW specific
details at all. Certain exceptions to this rule make sense, I agree,
but they must be considered carefully.
>
> > Maybe I haven't understood what this is good for. Maybe it is just the
> > confusion of terms.
>
> Darn! What I offered later in the mail thread you didn't see value in,
> either. I'll either have to send you to some white papers talking about
> other products doing QoS, or think of a better example for you...
I did see the examples later in the message.
So far X doesn't send QoS messages to the user.
Most of the time these things are expected to be handled by the
driver as good as it can. If it cannot handle them the condition
is usually fatal anyway. Such things get recorded in the log file
as this is something the 'administrator' will have to deal with.
When a read returns unexpectedly this usually doesn't point to
a problem the user can deal with. If somebody cuts the cable
this would either result in a normal unplug event (in case of a USB
device) with the result that the client will receive the message
that the device has been unregistered or remain unnoticed altogether
(serial device).
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.
>
> > That's a different client than what I'm calling a client. OK, I should
> > call my client an X-client.
> > I don't think this needs to live in it's own thread. You have to
> > open a /dev/something and listen for messages, don't you? No reason
> > to have a separate thread there.
>
> Don't forget, the same select() loop also receives X events and you
> don't want the server to appear sluggish while dealing with non-core
> events. So yeah, spawning a thread to deal with them is not a bad idea.
>
How much traffic do you expect?
> >
> > Right. That's what we need a registry for.
>
> I think your registry would know how to identify hardware and determine
> the correct drivers to load.
>
> But are you also suggesting that it knows how to ask the NVidia driver
> for its video resolution (e.g., it prefers a message in string format
> like, "reso?", whereas the C&T driver might use a different message?)
That's why we need a registry. And I don't like string messages
either. This is the current ad hoc implementiaton.
>
> > > Let's all get out the USB HID documentation and rip to pieces what's
> > > wrong/vague/ill considered in their teminology, then we'll have the
> > > beginnings of a wrong/vague etc., language for talking to drivers...
> >
> > OK, you want to start with the HW interface.
>
> Ah, no. HID tries to standardize hardware attributes for different
> devices into common terminology. Then they define standard messages for
> setting attributes and querying attributes from the hardware, given a
> standardized "language". (Actually, enums) Their specs barely
> acknowledge that it's running on USB :-)
OK.
>
> But it's the beginning of figuring out what attributes different types
> of hardware would have, and creating standardized terms for everything.
> (I believe) they made a few mistakes, but it's still something to learn
> from.
OK.
>
> The XI needs to be
> > entirely independent of this. It must abstract the entire HW if
> > and needs to be generic enough to permit different HW interfaces.
> > In prinicple both should be developed independently by different
> > groups. Otherwise the XI X-client interface will be implemented
> > too much along the OS specific HW interface.
>
> Completely agree. The X-client interface should only be concerned with
> the message format.
>
OK.
Cheers,
Egbert.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
