Re: Multiple Monitors
Alan Hourihane wrote: I prefer option 2 because of its fewer levels of SubSections. What's the replacement for the metamodes option/concept? Will this survive? No. Hm. In that case, I don't think this is a real step forward. It requires more configuration data instead of less: Only for simple configurations... read on. The current implementation (at least in the SiS driver, can't really speak for the others), the Modes in the Display subsection are the pool from which the meta modes are composed. All modes in that (yet single) Display subsection are checked against the specs of *both* output devices (which are the Monitor section for device 1, and specific options in the Device section for the second; in both cases unless we have DDC data). If they pass this check, they can be part of a meta mode. Your modification forces the user, more or less, to enter the same data twice. I don't really see the advantage, except that it's maybe more intuitive to read the config file but that is assumingly not the goal. The fact is, more and more video cards are getting multiple heads. Even the Matrox Parhelia can drive 3 monitors. I know of others than can drive 4 monitors and it's just not user friendly/scalable with the current setup. No question. Agreed. As all the drivers seem to have their own implementation (albeit similar) AFAIK only 3 open source drivers support mergedfb yet: Matrox, SiS and radeon (in the DRI trunk). Radeon's code is nearly if not entirely identical with the SiS code as Alex Deucher took my SiS code and inserted it into the radeon driver. As regards pseudo-xinerama, I think the SiS driver is the only one currently (unsure if Alex took that over, too). The Matrox driver has no such feature. I don't think the OSX implementation is similar enough to make use of unified code but that's up the Apple folks to judge. The options (and their names) of all three drivers supporting mergedfb are identical; they are, conceptwise, mostly even identical to the binary NVidia driver (except that the open source drivers don't support panning domains - however useful that is anyway). (Hm, reading this might make one think that there already is something like a standard) it clutters up drivers with very very similar code too. Agreed. Yes, there might be more config to do in the config file, but the tools to setup these up hide a lot of that already. Hell, I'll even make the -configure option do the right thing too. OK In case you mean that the resolution changes in the same order the modes are given in these two Monitor sections, I find this far less easy to configure (one has to count the Modes to see which ones are being combined, etc.) And how are clone/zoom modes being configured? I'm open to suggestions on how to deal with all this, and that's why I brought it up. The current situation of 'let the driver deal with it' is just ripe for getting out of control. I am not against your idea at all, in case I made this impression. I just wanted to point out that just monitor configuration is by far not sufficient. The following is meant to give a short overview and as a basis for comments for a new configuration implementation: Summarized, the criteria for configuring mergedfb mode are - monitors and their specs; that is what your proposal so far took care of, - relative position = orientation (mon A left/right of/above/below mon B; that can be extended to 3 or 4 or whatever number of monitors easily: mon c above mon b, mon d above mon a etc) and clone/zoom (=both/all show the same image, possibly with a zoom facility) - mode selection for each monitor (read: output device); there the problem starts. As I said, right now, the drivers use the (only) Modes list as the pool, and the MetaModes statement for combining these modes. What I would find highly unpractical is leaving this out entirely and use the Modes given in the new Monitor Subsections as the modes the driver should use - in that order. From my experience, users think more in a whole when configuring mergedfb mode. Meaning that the emphasis is on the respective modes used on each output device _at_the_same_time_ = metamode. A plain list of modes for each monitor (of which assumingly many will be skipped when they exceed the specs) makes server behavior highly uncomprehendable from a user's point of view: If one or the other mode is deleted from the list, the whole list is shifted, and hence the result is an entirely different one. I find the MetaModes concept, even if perhaps not the most intuitive, but a very useful one. This, of course, cries for comments. (From anyone, that is. Alex? Mark?) - virtual screen dimension: The user should not be forced to calculate anything. Hence, this must be done automcatically. - DPI: Big problem, inherent to all multi-monitor implementations. - automatic configuration (in case the user does not give all the above with options; such as
Re: Multiple Monitors
On Tue, 2 Mar 2004, Alan Hourihane wrote: I mentioned in a reply to Alex, that maybe the ScreenLayout section should use Monitor's rather than Screens. I think that should fix the orientation issues, as the ScreenLayout is really describing the monitor positions. I didn't spot this the first time around. At present there is no need for two monitor sections when you have two identical monitors, as each Screen can use the same Monitor. Don't know whether that change is important. So you'd only use the modes for the second monitor that is described for the primary monitor ? I'm not keen on that. Some people will have two very different monitors, and many of the Matrox cards support more modes (RAMdac bandwidth limits) on one head than the other. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
--- Thomas Winischhofer [EMAIL PROTECTED] wrote: Alan Hourihane wrote: I prefer option 2 because of its fewer levels of SubSections. What's the replacement for the metamodes option/concept? Will this survive? No. Hm. In that case, I don't think this is a real step forward. It requires more configuration data instead of less: Only for simple configurations... read on. The current implementation (at least in the SiS driver, can't really speak for the others), the Modes in the Display subsection are the pool from which the meta modes are composed. All modes in that (yet single) Display subsection are checked against the specs of *both* output devices (which are the Monitor section for device 1, and specific options in the Device section for the second; in both cases unless we have DDC data). If they pass this check, they can be part of a meta mode. Your modification forces the user, more or less, to enter the same data twice. I don't really see the advantage, except that it's maybe more intuitive to read the config file but that is assumingly not the goal. The fact is, more and more video cards are getting multiple heads. Even the Matrox Parhelia can drive 3 monitors. I know of others than can drive 4 monitors and it's just not user friendly/scalable with the current setup. No question. Agreed. As all the drivers seem to have their own implementation (albeit similar) AFAIK only 3 open source drivers support mergedfb yet: Matrox, SiS and radeon (in the DRI trunk). Radeon's code is nearly if not entirely identical with the SiS code as Alex Deucher took my SiS code and inserted it into the radeon driver. As regards pseudo-xinerama, I think the SiS driver is the only one currently (unsure if Alex took that over, too). The Matrox driver has no such feature. I don't think the OSX implementation is similar enough to make use of unified code but that's up the Apple folks to judge. Yup, I ported pseudo-xinerama over to radeon as well. I also plan to bring the mga driver up to speed with the other drivers as time allows, pending ryan's re-work of the dualhead/dvi stuff. The options (and their names) of all three drivers supporting mergedfb are identical; they are, conceptwise, mostly even identical to the binary NVidia driver (except that the open source drivers don't support panning domains - however useful that is anyway). (Hm, reading this might make one think that there already is something like a standard) it clutters up drivers with very very similar code too. Agreed. Yes, there might be more config to do in the config file, but the tools to setup these up hide a lot of that already. Hell, I'll even make the -configure option do the right thing too. OK In case you mean that the resolution changes in the same order the modes are given in these two Monitor sections, I find this far less easy to configure (one has to count the Modes to see which ones are being combined, etc.) And how are clone/zoom modes being configured? I'm open to suggestions on how to deal with all this, and that's why I brought it up. The current situation of 'let the driver deal with it' is just ripe for getting out of control. I am not against your idea at all, in case I made this impression. I just wanted to point out that just monitor configuration is by far not sufficient. The following is meant to give a short overview and as a basis for comments for a new configuration implementation: Summarized, the criteria for configuring mergedfb mode are - monitors and their specs; that is what your proposal so far took care of, - relative position = orientation (mon A left/right of/above/below mon B; that can be extended to 3 or 4 or whatever number of monitors easily: mon c above mon b, mon d above mon a etc) and clone/zoom (=both/all show the same image, possibly with a zoom facility) - mode selection for each monitor (read: output device); there the problem starts. As I said, right now, the drivers use the (only) Modes list as the pool, and the MetaModes statement for combining these modes. What I would find highly unpractical is leaving this out entirely and use the Modes given in the new Monitor Subsections as the modes the driver should use - in that order. From my experience, users think more in a whole when configuring mergedfb mode. Meaning that the emphasis is on the respective modes used on each output device _at_the_same_time_ = metamode. A plain list of modes for each monitor (of which assumingly many will be skipped when they exceed the specs) makes server behavior highly uncomprehendable from a user's point of view: If one or the other mode is deleted from the list, the whole list is shifted, and hence the result is an entirely different one. I find the MetaModes concept, even if
RE: XAA2 namespace?
On Mon, 2004-03-01 at 18:58 -0800, Mark Vojkovich wrote: On Mon, 1 Mar 2004, Sottek, Matthew J wrote: Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt It depends what you'd like to discuss. I already have a working implementation. It does not preclude usage of the old XAA. A driver can use either one. Nobody has to touch old drivers if they don't want to. Anything you can post here? Would an XAA2 driver be more easily usable in other scenarios than XFree86, eg SkyOs etc? The goals of XAA2 are: 1) Smaller. It's currently about one fifth the XAA size. There was too much benchmark rigging in XAA. It's not justified. 2) Following from #1, all of the optimizations for hardware with MMIO interfaces has been removed. XAA spent alot of code on CPU/GPU interleaving. Command buffer-based engines don't care about this. XAA2 will be slower in x11perf on MMIO engines but about the same as XAA for command buffer engines. 3) No assumptions about offscreen memory usage. Leave it entirely up to the driver. I'll provide a sample linear heap manager. You can use whatever you want. 4) Messy stuff like the triple-bits and rgb-equal in XAA will not be supported except as a complete fallback to software at GC validation time. There is no per-primitive GC validation like there was in XAA because apps just don't work that way. They trash validation so much that it needs to be lightweight. Mark. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Vojkovich Sent: Monday, March 01, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: XAA2 namespace? The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- Torgeir Veimo [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
Alex Deucher wrote: I agree. I think metamodes are kind of klunky, but I don't know what a better solution would be off hand. Another thing about the proposed solution is that in many drivers certain configurations are assumed, which can be confusing in the screen setup. For instance in the radeon driver, the DVI/lvds port is always primary. What's the primary? Since I can put the devices left-right or right-left, primary is IMHO only relevant for Xinerama and/or applications drawing fixed conclusions. (And for the record: The SiS driver needs to treat CRT2 as some sort of primary as well, due to order-of-init reasons required by the hardware. CRT2 can be TV, LCD=DVI-D or VGA2=DVI-A. CRT1 can only be VGA. I also need to know all about the configuration for CRT2 before I can eg. calculate the maximum pixel clocks for CRT1, etc etc etc) It might almost be a better idea to work the other way around. standardize the mergedfb backend stuff (pseudo-xinerama, metamode parsing, pointermoded(), etc.) and then just standardize on options for the drivers. Maybe instead of messing with the monitors in the screen section, allow the user to specify them in the device section like Alan mentioned earlier, something like: option crt2monitor Monitor1 That is an alternative, indeed. And it would be much easier to implement since there is no old version-style and new-version-style XF86Config then (which I wouldn't know how to distinguish between). The disadvantage is that you blast the chain of / Monitor Screen ---x \-Device by directly linking the Device and Monitor section. Dogmatically that isn't really beautiful. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 05:56:01AM -0800, Alex Deucher wrote: As regards pseudo-xinerama, I think the SiS driver is the only one currently (unsure if Alex took that over, too). The Matrox driver has no such feature. I don't think the OSX implementation is similar enough to make use of unified code but that's up the Apple folks to judge. Yup, I ported pseudo-xinerama over to radeon as well. I also plan to bring the mga driver up to speed with the other drivers as time allows, pending ryan's re-work of the dualhead/dvi stuff. Yeah, I need to get back to that. I got sidetracked with studies and the last weekend was eaten trying to beat some sense into the rendition driver. Did you ever get your G550? I have two systems now, one with DH G400 and one with SH G400 + a millenium II. So hopefully I can at least verify that me stuff is working on at least one DH card and at least one multi-mga configuration. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 10:10:40PM +, Alan Hourihane wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. The approach I was following up a while ago but never finished was something like this: Section Screen Identifier Screen0 Device Videocard0 Monitor 0 Monitor0 Monitor 1 Monitor1 RightOf Monitor0 DefaultDepth 24 SubSection Display Depth 16 Virtual 0 1600 1200 Virtual 1 1024 768 Modes 0 1600x1200 1280x1024 1024x768 Modes 1 1024x768 800x600 640x480 EndSubSetion SubSection Display Depth 24 Virtual 0 1600 1200 Virtual 1 1024 768 Modes 0 1600x1200 1280x1024 1024x768 Modes 1 1024x768 800x600 640x480 EndSubSetion EndSection Explicitly tying numbers to the monitor entries would be optional, as would supplying per-monitor parameters in the Display subsections. The idea of MetaModes (i.e., mode combinations) that I think Andy Ritger mentioned a while back would be useful too. Figuring out how the configuration information is represented will be useful in working out how to represent the information internally for the drivers. As much as possible should be auto-configured by default though. I got the parser changes, and the data structure changes done, and had made a start on the other pieces. Allowing a high level of flexibility in the configuration syntax was complicating the implementation though. It might be that a different method would simplify that, which would definitely be a good thing. Option 1 Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection Or, Option 2. Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor0 Depth 24 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor1 Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSection I'd prefer option 2 out of these because of the reduced redundancy. If we want to handle meta modes, perhaps they could be handled via a regular Display subsection. You then need a method for specifying the monitor layout. I chose an approach analogous to how we specify the layout of multiple screens, and that should work here too. Additional things come up, like how the monitor view port moves within the logical screen, how the mode switching hot keys work, etc. I'd suggest we come up with something that can cope with the types of things we expect to need, get the basics implemented first, then get into the nitty gritty details of some of the fancier stuff. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
Is the Nvidia closed source driver based on a early version off Xaa2? Mark Vojkovich wrote: On Mon, 1 Mar 2004, Sottek, Matthew J wrote: Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt It depends what you'd like to discuss. I already have a working implementation. It does not preclude usage of the old XAA. A driver can use either one. Nobody has to touch old drivers if they don't want to. The goals of XAA2 are: 1) Smaller. It's currently about one fifth the XAA size. There was too much benchmark rigging in XAA. It's not justified. 2) Following from #1, all of the optimizations for hardware with MMIO interfaces has been removed. XAA spent alot of code on CPU/GPU interleaving. Command buffer-based engines don't care about this. XAA2 will be slower in x11perf on MMIO engines but about the same as XAA for command buffer engines. 3) No assumptions about offscreen memory usage. Leave it entirely up to the driver. I'll provide a sample linear heap manager. You can use whatever you want. 4) Messy stuff like the triple-bits and rgb-equal in XAA will not be supported except as a complete fallback to software at GC validation time. There is no per-primitive GC validation like there was in XAA because apps just don't work that way. They trash validation so much that it needs to be lightweight. Mark. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Vojkovich Sent: Monday, March 01, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: XAA2 namespace? The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
Will there be open discussion of what makes up Xaa? I know
you have already have a working design but rather than accept
major changes wholesale can we discuss the finer points before
they become defacto-accepted.
-Matt
It depends what you'd like to discuss. I already have a
working implementation. It does not preclude usage of the
old XAA. A driver can use either one. Nobody has to
touch old drivers if they don't want to.
I'd like to discuss the design details. Why don't you send the
relevant parts of the header to the list for discussion before
you commit it? Lets face it, once the code is committed there
is not going to be as much room for change. If Xaa is being
replaced then it seems fitting that everyone have a chance to
review and comment on the design before it is committed.
1) Smaller. It's currently about one fifth the XAA size. There
was too much benchmark rigging in XAA. It's not justified.
Smaller is good, but can you give an example of benchmark
rigging?
3) No assumptions about offscreen memory usage. Leave it entirely
up to the driver. I'll provide a sample linear heap manager.
You can use whatever you want.
So is the new design surface based? i.e. blits are coordinates
relative to a surface (off-screen or on-screen). If so, this is
good. The rectangular memory single surface Xaa is not a very
good match for modern hardware.
Also, I would like to make sure that the new design has a much
improved syncing mechanism. Syncing should be, at a minimum,
on a per-surface basis. Perhaps even a bounded region of a
surface is justified. As GUI's become more media rich the
amount of data coming from the CPU to the graphics engine is
increasing. This means more puts and consequently lots of syncing
for many hardware types. The current global sync design waits
too long and forces idle time unnecessarily. Other driver models
abandoned the single sync a long time back.
I think we should also address the setup for...subsequent
design concept. Seems like most designs would be better fit
with a single entry point that provides all the information,
perhaps with an n option to indicate how many such calls are
expected with the same setup data. Command engines could then
batch commands together, or a driver could send a batch of
commands to a kernel driver. In my opinion it is more useful to
know how many similar commands are being sent (or at least know
when the last one is sent) than the current method.
Currently:
setup_for_foo()
while(i--) {
subsequent_foo()
}
could be
while(i--) {
do_foo(i);
}
or alternatively (if you can't know how many until you are done)
while(i--) {
do_foo();
}
last_foo();
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 11:09:23PM +, Alan Hourihane wrote: On Mon, Mar 01, 2004 at 02:57:50PM -0800, Alex Deucher wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. Indeed. So I'd let to get this first step of modifying the config file out of the way so all the other pieces can drop into place. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? I'm not sure what the best way to handle that is. Actually, you bring up a good point with orientation, and it's making me rethink a little. Maybe we need to be a little more radical with the changes and change the ServerLayout to accept Monitor configurations instead of Screen sections as essentially that's how it's really tied down. You don't have the same freedom with placement of monitors as you do with screens. For example, you can't have the screen of a second card placed in between two monitors of the first card. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 04:11:02PM -0800, Mark Vojkovich wrote: On Mon, 1 Mar 2004, Alan Hourihane wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. Option 1 Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection I prefer #1. You might want to look into NVIDIA's TwinView options. That is, stuff like orientation and panning domains. And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. When I was looking at this, I was adding the new fields at the end, and filling in the current fields with the first monitor's data for compatibility with drivers that don't look beyond that. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
--- Sottek, Matthew J [EMAIL PROTECTED] wrote: Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt It depends what you'd like to discuss. I already have a working implementation. It does not preclude usage of the old XAA. A driver can use either one. Nobody has to touch old drivers if they don't want to. I'd like to discuss the design details. Why don't you send the relevant parts of the header to the list for discussion before you commit it? Lets face it, once the code is committed there is not going to be as much room for change. If Xaa is being replaced then it seems fitting that everyone have a chance to review and comment on the design before it is committed. good alpha channel support would be nice too, although that might require some other changes. Alex [snip] __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 01:18:20AM +0100, Thomas Winischhofer wrote: Alex Deucher wrote: I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. AFAIK, the OSX port uses the same pseudo stuff that we use. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? At what place in the list? Confusing the user is the least we want, especially with that already quite complicated concept of mergedfb. I think the goal here is provide a simpler and more regular method of handling this stuff, but with a basis that is flexible enough to handle expected needs without going through this again in the near future. Clone and zoom are all special cases of a more general monitor layout mechanism, which is really all about how you postion the multiple view ports into the single screen and how you handle mode switching. Allowing these things to be changed/configured on the fly makes it even more interesting, and will go some way to simplifying real-world configuration. Open question: does the newly (or nearly?) standardised Xinerama extension allow for the physical screen layout to be changed at runtime? It needs to for a least this pseudo Xinerama case. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 12:32:08PM +, Dr Andrew C Aitchison wrote: On Tue, 2 Mar 2004, Alan Hourihane wrote: I mentioned in a reply to Alex, that maybe the ScreenLayout section should use Monitor's rather than Screens. I think that should fix the orientation issues, as the ScreenLayout is really describing the monitor positions. I didn't spot this the first time around. At present there is no need for two monitor sections when you have two identical monitors, as each Screen can use the same Monitor. Don't know whether that change is important. That is an important point. Now that you mention it, I ran into the same issue in handling the monitor layout with the method I was looking at. It makes referring to monitors by Id alone ambiguous. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 12:59:52PM -0500, David Dawes wrote: Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection I prefer #1. You might want to look into NVIDIA's TwinView options. That is, stuff like orientation and panning domains. And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. When I was looking at this, I was adding the new fields at the end, and filling in the current fields with the first monitor's data for compatibility with drivers that don't look beyond that. BTW, while we are at it, please let's add support for depth independent modelines. Something like : SubSection Display Depth 16 24 Modes1024x768 800x600 640x480 EndSubSection Or even : SubSection Display Modes1024x768 800x600 640x480 EndSubSection Which would use the modes for all depth. I doubt newer cards have per depth modes limitations anymore. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 2 Mar 2004, [ISO-8859-1] Frank Gießler wrote: Mark Vojkovich wrote: We don't care what the filenames are except for the header files. The only reason why we care about header files is that a driver might include support for both and may need both include paths. There's only one exported header file. I'd like to name it Xaa.h to match the namespace. Is it really going to be relevant on case-unaware systems? Which ones are those BTW? There is already xaa.h. Having Xaa.h included at the same time is a no-op for OS/2, for which there are already binaries for 4.4.0 available (I would therefore consider this a well supported platform). Well, then I guess I could call the header file xaa2.h Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 2 Mar 2004, Knut J Bjuland wrote: Is the Nvidia closed source driver based on a early version off Xaa2? The NVIDIA binary driver has a stripped-down and slightly hacked up version of XAA2 in it. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, Mar 02, 2004 at 10:57:04AM -0800, Mark Vojkovich wrote: On Tue, 2 Mar 2004, [ISO-8859-1] Frank Gießler wrote: Mark Vojkovich wrote: We don't care what the filenames are except for the header files. The only reason why we care about header files is that a driver might include support for both and may need both include paths. There's only one exported header file. I'd like to name it Xaa.h to match the namespace. Is it really going to be relevant on case-unaware systems? Which ones are those BTW? There is already xaa.h. Having Xaa.h included at the same time is a no-op for OS/2, for which there are already binaries for 4.4.0 available (I would therefore consider this a well supported platform). Well, then I guess I could call the header file xaa2.h Not to be too picky, but won't this be the third version of XAA, not the second? David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, Mar 02, 2004 at 07:18:37PM +0100, Sven Luther wrote: On Tue, Mar 02, 2004 at 12:59:52PM -0500, David Dawes wrote: Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection I prefer #1. You might want to look into NVIDIA's TwinView options. That is, stuff like orientation and panning domains. And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. When I was looking at this, I was adding the new fields at the end, and filling in the current fields with the first monitor's data for compatibility with drivers that don't look beyond that. BTW, while we are at it, please let's add support for depth independent modelines. Something like : SubSection Display Depth 16 24 Modes1024x768 800x600 640x480 EndSubSection Or even : SubSection Display Modes1024x768 800x600 640x480 EndSubSection Which would use the modes for all depth. I doubt newer cards have per depth modes limitations anymore. I already did the latter for 4.4.0 as part of the auto-configuration work. The Display subsection and Monitor sections are entirely optional too. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 2 Mar 2004, David Dawes wrote: On Tue, Mar 02, 2004 at 10:57:04AM -0800, Mark Vojkovich wrote: On Tue, 2 Mar 2004, [ISO-8859-1] Frank Gießler wrote: Mark Vojkovich wrote: We don't care what the filenames are except for the header files. The only reason why we care about header files is that a driver might include support for both and may need both include paths. There's only one exported header file. I'd like to name it Xaa.h to match the namespace. Is it really going to be relevant on case-unaware systems? Which ones are those BTW? There is already xaa.h. Having Xaa.h included at the same time is a no-op for OS/2, for which there are already binaries for 4.4.0 available (I would therefore consider this a well supported platform). Well, then I guess I could call the header file xaa2.h Not to be too picky, but won't this be the third version of XAA, not the second? Yes, it's actually the third. Harm's was the first. I think we even advertised XFree86 4.x's XAA as 2.0. Would you prefer xaa3.h ? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
David Dawes wrote: On Tue, Mar 02, 2004 at 01:18:20AM +0100, Thomas Winischhofer wrote: Alex Deucher wrote: I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. AFAIK, the OSX port uses the same pseudo stuff that we use. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? At what place in the list? Confusing the user is the least we want, especially with that already quite complicated concept of mergedfb. I think the goal here is provide a simpler and more regular method of handling this stuff, but with a basis that is flexible enough to handle expected needs without going through this again in the near future. Clone and zoom are all special cases of a more general monitor layout mechanism, which is really all about how you postion the multiple view ports into the single screen and how you handle mode switching. Allowing these things to be changed/configured on the fly makes it even more interesting, and will go some way to simplifying real-world configuration. Open question: does the newly (or nearly?) standardised Xinerama extension allow for the physical screen layout to be changed at runtime? It needs to for a least this pseudo Xinerama case. Exactly. However, since I found that changing it run-time either has no effect (so with kde) or seriously confuses apps (many examples) I don't do it now. I just calculate a basic setup (based on the orientation and the meta modes) and use this through out the session. It's no problem with Xinerama, it's a problem with the apps. (Or, well, perhaps Xinerama, too, in case it lacks a facility to notify clients of changes which I don't remember) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 2004-03-02 at 21:06, Mark Vojkovich wrote: On Tue, 2 Mar 2004, David Dawes wrote: On Tue, Mar 02, 2004 at 10:57:04AM -0800, Mark Vojkovich wrote: Well, then I guess I could call the header file xaa2.h Not to be too picky, but won't this be the third version of XAA, not the second? Yes, it's actually the third. Harm's was the first. I think we even advertised XFree86 4.x's XAA as 2.0. Would you prefer xaa3.h ? As everyone knows, counting starts at 0, so xaa2 in fact denotes the third XAA. :) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Tue, 2 Mar 2004, Sottek, Matthew J wrote: It's currently global because the hardware I work on doesn't have to fall back to software very often. Bookkeeping on a per- surface basis is a simple modification and one I will add. This precludes using XAA2 with hardware that doesn't support concurrent SW and HW access to the framebuffer, but that's OK since that stuff is old and we're trying to move forward here. HW that sucks can use the old XAA. It shouldn't preclude this from working. You just need the call to look like sync(xaa_surface_t *surface) and let old hardware sync the whole engine regardless of the input. It helps those who can use it and is the same as what you have now for everyone else. I don't understand your reasoning. The difference with per-surface as opposed to global sync state is that you don't have to sync when CPU rendering to a surface that has no previously unsynced GPU rendering. The point of this is to ALLOW concurrent CPU and GPU rendering into video ram except in the case where both want to render to the same surface. There are old hardware that allow no concurrent CPU and GPU rendering at all. Even with Sync() passing the particular surface which is necessitating the sync, I would expect all drivers to be syncing the whole chip without caring what the surface was. Most hardware allow you to do checkpointing in the command stream so you can tell how far along the execution is, but a Sync can happen at any time. Are you really going to be checkpointing EVERY 2D operation? I still contend that it would be a benefit to know how many rects associated with the same state are going to be sent (even if you send those in multiple batches for array size limitations) this allows a driver to batch things up as it sees fit. I don't know the amount of data coming. The old XAA (and cfb for that matter) allocated the pathelogical case: number of rects times number of clip rects. It doesn't know how many there are until it's done computing them, but it knows the upper bounds. I have seen this be over 8 Meg! The new XAA has a preallocated scratch space (currently a #define for the size). When the scratch buffer is full, it flushes it out to the driver. If XAA is configured to run with minimal memory, the maximum batch size will be small. Currently a driver cannot batch things efficiently because there is no way to know when the end of the batch should happen. An array of rects is a good start but not a complete solution. It's the best we can do. I'm not going to compute the clips in two passes: one to find out how many rects there end up being, and one to store the rects. I also have some questions regarding the memory management. Who is responsible for system memory surfaces (and any migration to/from video memory)? System memory pixmaps are handled by fb as always. XAA2 holds the migration logic. Who is responsible for populating surfaces? Does X get a virtual address (or offset from base), width, height, pitch and populate the surface itself or does the driver have to handle cpu_to_screen to do it? What about unknown surface types? (compressed?) XAA doesn't care about surface particulars. It asks the driver if it could stick this pixmap in videoram for it because the migration logic says it should go in videoram. The driver can refuse or can accept by returning an XAASurface for it. XAA passes that surface back to you in the SetupFor function. To XAA, it's just a device independent structure. The driver has private storage in the XAASurface. How does X tell the driver what the surface will be used for? A RENDER surface could have different alignment or tiling properties than a 2d only surface. That information would be needed at allocation time. There's no such thing as a RENDER surface. Pictures are merely X-drawables with extra state associated with them. Any drawable can eventually be used as a picture. You will need to keep that in mind just as you do now. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
how to get correct image after switch to other terminal
Hi All, I wrote a X11 application to get image of some window by XGetImage(),but after i switch to other terminal by Ctrl+Alt+F2,my application can't get correct image of windows.Are there any idea to fix this problem? or how can X11 application to know if desktop has been switch to another terminal? Thanks! wjd ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Tue, 2 Mar 2004, Sottek, Matthew J wrote: Also, I would like to make sure that the new design has a much improved syncing mechanism. Syncing should be, at a minimum, on a per-surface basis. Perhaps even a bounded region of a surface is justified. As GUI's become more media rich the amount of data coming from the CPU to the graphics engine is increasing. This means more puts and consequently lots of syncing for many hardware types. The current global sync design waits too long and forces idle time unnecessarily. Other driver models abandoned the single sync a long time back. Ummm... which other models are you refering to? I'm told that Windows does it globally. Having per-surface syncing may mean you end up syncing more often. Eg. Render with HW to one surface then to another, then if you render to SW to both of those surfaces, two syncs happen. Doing it globally would have resulted in only one sync call. Unless you can truely checkpoint every rendering operation, anything other than global syncing is going to result in more sync calls. The more I think about going away from global syncing, the more this sounds like a bad idea. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: how to get correct image after switch to other terminal
On Wed, 3 Mar 2004, wjd wrote: Hi All, I wrote a X11 application to get image of some window by XGetImage(),but after i switch to other terminal by Ctrl+Alt+F2,my application can't get correct image of windows.Are there any idea to fix this problem? or how can X11 application to know if desktop has been switch to another terminal? Thanks! There is no image when you are switched away. I'm not sure about how to figure out how to tell when switched away. I thought there was something in the XFree86-VidModeExtension, but it looks like there isn't. Certainly, you could monitor the visibility events on the window you are grabbing. If it's fully obscured, there's nothing to see. MArk. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
