From: Ian R. <id...@us...> - 2003-01-28 21:31:36
|
D. Hageman wrote: > On Tue, 28 Jan 2003, Ian Romanick wrote: > >>How do we want to handle the case where a user changes video cards? >>Some of the parameters are likely to be generic, but a lot will be very >>device specific. The issue here is that the set of available parameters >>will change. A releated issue is when the set of availble parameters >>change from one driver release to another. So, do we want to key >>options on hardware device, screen (in the X sense), or something else? >> The answer to this question will likely dictate how we handle multi-head. > > The more I play around with this in my head the more I lean towards keying > to the device. The screen is a very generic term and it is supposed to be > that way for the abstraction of X11 to work. It however does not lend > itself to specific driver tweaking ... hence why the option parameters go > in the "Device" section. What would we use as the device key, then? Would this match the device's name from the XF86Config file? There are a few odd corner cases that we need to make sure and get right the first time. User's changing cards and multi-head cards (even though we don't support direct rendering on them now) are the two big ones that I can think of. >>I think we're going to end up with two keys. One is the application >>(with a default available) and the other will be something to identify >>the device and/or screen. How do we want to specify them? By this I >>mean, do we want to select the application then the screen (like you >>suggest above) or the other way around? > > In all honesty I threw out my example to start some discussion. Not too > much thought had went into it. I saw a couple let us see a schema posts > so I thought I would see what happen if I posted one. I think the real > way it should be done is device, then application. > > <device id="0"> > <application name="... > ... > </application> > <application name="... > ... > </application> > </device> I'm coming to conclusion more the more I think about it. I really can't come up with a good, real-world case to argue for application-then-device. Most of the cases where you'd want the application at the top level could be handled by putting a '<device id="*">' around it. |
From: Russ D. <Rus...@as...> - 2003-01-28 21:43:55
|
> > <device id="0"> > > <application name="... > > ... > > </application> > > <application name="... > > ... > > </application> > > </device> > > I'm coming to conclusion more the more I think about it. I really can't > come up with a good, real-world case to argue for > application-then-device. Most of the cases where you'd want the > application at the top level could be handled by putting a '<device > id="*">' around it. I would think that the common case would be: most general settings device 0 settings device 1 settings application x settings settings specific to device 0 on application x etc I don't think "settings specific to device 0 on application x" would ever actually come up, but the structure suggested would allow it. -- Russ Dill <Rus...@as...> |
From: D. H. <dha...@dr...> - 2003-01-28 23:55:40
|
On Tue, 28 Jan 2003, Ian Romanick wrote: > D. Hageman wrote: > > On Tue, 28 Jan 2003, Ian Romanick wrote: > > > >>How do we want to handle the case where a user changes video cards? > >>Some of the parameters are likely to be generic, but a lot will be very > >>device specific. The issue here is that the set of available parameters > >>will change. A releated issue is when the set of availble parameters > >>change from one driver release to another. So, do we want to key > >>options on hardware device, screen (in the X sense), or something else? > >> The answer to this question will likely dictate how we handle multi-head. > > > > The more I play around with this in my head the more I lean towards keying > > to the device. The screen is a very generic term and it is supposed to be > > that way for the abstraction of X11 to work. It however does not lend > > itself to specific driver tweaking ... hence why the option parameters go > > in the "Device" section. > > What would we use as the device key, then? Would this match the > device's name from the XF86Config file? It would have to as no other keying would be reasonable or at least none that I can think of at the momment. > There are a few odd corner cases that we need to make sure and get > right the first time. User's changing cards and multi-head cards (even > though we don't support direct rendering on them now) are the two big ones > that I can think of. The way I see some of this is that we just don't have the capability of being super smart about some of this. If a person changes a card then it would indeed invalidate the DRI configuration if it isn't the same variety of card. I don't think that in and of itself is an unreasonable expection. It would be nice to be able to provide some feedback to the user and claim that they have done something screwy. Part of this endeavor should standardize at least the basic configuration options so at least the configuration should be ... reasonably unusable if a card was switched. On a multi-head box the device names should be different so we should be convered there, right? > I'm coming to conclusion more the more I think about it. I really can't > come up with a good, real-world case to argue for > application-then-device. Most of the cases where you'd want the > application at the top level could be handled by putting a '<device > id="*">' around it. Sounds good - I think I am right there along beside on that one. Let me mention as a footnote that I will be out of town starting tomorrow evening. I have to make a quick trip over the big blue pond to see some friends so after tonight I won't be taking part in this discussion until early next week. -- //========================================================\\ || D. Hageman <dha...@dr...> || \\========================================================// |
From: Philip B. <ph...@bo...> - 2003-01-28 22:10:32
|
On Tue, Jan 28, 2003 at 09:56:09PM +0000, Sergey V. Oudaltsov wrote: > Hi > > Just one little XFree-related pro-XML story. Not from DRI, from XKB > life. You know, XKB configuration is generally held in > /usr/X11R6/lib/xkb directory and several subdirectories. All this would > be fine if the format of the files in these directories would be > something good, structured, readable (by human and machine). But > historically it never was. .[...] Good story. But right there, you point out the main difference between your example, and the XFree86 config format. BTW: I hope you folks will fix it so that it is finally possible to have /usr/X11R6 be read-only The only culprit stopping this, as far as I know, is the xkb stuff. |
From: Sergey V. O. <ser...@cl...> - 2003-01-28 22:50:27
|
> Good story. But right there, you point out the main difference between yo= ur > example, and the XFree86 config format. Keep in mind - it is not XF68Config, it is just configuration repository. The tree of available modeuls/layouts/variants/options. Not actually chosen one (which is still in XF86Config). So it is just one very large (especially in future - with all translations) read-only XML file. > The only culprit stopping this, as far as I know, is the xkb stuff. Actually I did not hear about it. What is the problem here? I'm afraid it is xkbcomp which spoils things - though I can be wrong. Well, we are going offtopic. Shall we continue about XKB here? Cheers, --=20 Sergey |