Some questions regarding locks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking whether the caller actually holds the global lock. There is no LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has no check in it either. Did I miss something, or is this intended behaviour? It certainly seems strange to me. Also, it is possible for a DRI client to effectively lock up the entire machine simply by entering an endless loop after taking the lock. I suppose one could still log in remotely and kill the offending process, but that's not a realistic option for most people. Switching to a different VT or killing the X server does not work, because the X server has to take the DRI lock in the process. This is a problem that I want to fix (it makes playing around with the R300 hack Vladimir Dergachev posted an infinite-rebooting nightmare), but I am unsure what the best solution would be. As far as I can see, the problem is two-fold: One, the X server must be able to break the lock, and two, it (or the DRM) must somehow disable the offending DRI client to prevent the problem from reoccurring. I think the simplest solution would look something like this: Whenever DRM(lock) is called by a privileged client (i.e. the X server), and it needs to sleep because the lock is held by an unprivileged client, a watchdog timer is started before we schedule. DRM(unlock) unconditionally stops this watchdog timer. When the watchdog timer fires, it releases the lock and/or kills the offending DRI client. Side question: Is killing the offending DRI client enough? When the process is killed, the /dev/drm fd is closed, which should automatically release the lock. On the other hand, I'm pretty sure that we can't just kill a process immediately (unfortunately, I'm not familiar with process handling in the kernel). What if, for some reason, the process is in a state where it can't be killed yet? I guess this isn't a problem when we're dealing with a faulty 3D driver, but it might be a problem when dealing with malicious code. Side question #2: Is it safe to release the DRM lock in the watchdog? There might be races where the offending DRI client is currently executing a DRM ioctl when the watchdog fires. This solution involves no ABI changes. Since all changes are kernel side and affect only code that is shared between all drivers, everybody would benefit immediately. Does this all look reasonable to the DRI gurus? cu, Nicolai -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAr0G+sxPozBga0lwRAmqlAJ9fzmVB1t5D5Hqna3QoGD4zwv1suwCgqyZ1 tWYeGKKr22zwJuR3WNsFzjc= =M43m -END PGP SIGNATURE- --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Michel Dnzer wrote: On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: There are two types of VTs - text and graphical. It is only practical to have a single graphical VT because of the complexity of state swapping a graphical VT at VT swap. Right now we can all-ready run X on multiple VTs and with DRI-reinit can run GL apps on all of them. It may noy be the most elegant thing but it workes. We need the OS to keep state, even graphical, GART and all. I don't see how a 128M GART is diffrent then 2Gb system memory. Should we have GART swap space on the HD, a GART partition? I don't think so. The current scheme simply keeps clients from touching the hardware while switched away by blocking the hardware lock and invalidates all their hardware state when switching back. Maybe this could be extended with per-VT hardware locks. If something needs to be preserved while switched away, (a copy of) it should be kept in good old normal virtual memory. Or better still, those pages could be swapped out of the GART apperture the pages of the incoming VT swapped in. Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Can the GART apperture be moved physicaly? I don't think a logical move would be much help. --- Keith Whitwell [EMAIL PROTECTED] wrote: Michel Dänzer wrote: On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: There are two types of VTs - text and graphical. It is only practical to have a single graphical VT because of the complexity of state swapping a graphical VT at VT swap. Right now we can all-ready run X on multiple VTs and with DRI-reinit can run GL apps on all of them. It may noy be the most elegant thing but it workes. We need the OS to keep state, even graphical, GART and all. I don't see how a 128M GART is diffrent then 2Gb system memory. Should we have GART swap space on the HD, a GART partition? I don't think so. The current scheme simply keeps clients from touching the hardware while switched away by blocking the hardware lock and invalidates all their hardware state when switching back. Maybe this could be extended with per-VT hardware locks. If something needs to be preserved while switched away, (a copy of) it should be kept in good old normal virtual memory. Or better still, those pages could be swapped out of the GART apperture the pages of the incoming VT swapped in. Keith __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Some questions regarding locks
Nicolai Haehnle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking whether the caller actually holds the global lock. There is no LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has no check in it either. Did I miss something, or is this intended behaviour? It certainly seems strange to me. Also, it is possible for a DRI client to effectively lock up the entire machine simply by entering an endless loop after taking the lock. I suppose one could still log in remotely and kill the offending process, but that's not a realistic option for most people. Switching to a different VT or killing the X server does not work, because the X server has to take the DRI lock in the process. This is a problem that I want to fix (it makes playing around with the R300 hack Vladimir Dergachev posted an infinite-rebooting nightmare), but I am unsure what the best solution would be. If you're looking for ways to deal with debugging unstable drivers, I'm sorry but there's nothing that's going to come close to using two machines - one to do all your development, etc. on, and the other to continually reboot, crash, etc. as your test box. Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Yes the GART swap, if it needs to be done with memcpys, should be posponed untill the user has SOME type of interface. Thats the important thing, allowing the user to interact is above hardware based rendering. I never liked the way GLapps froze when they where not on the current VT. I think the answer too these problems is runnaway rendering, where the openGL calls simply return as thought they didn't do any thing. --- Holger Waechtler [EMAIL PROTECTED] wrote: Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: There are two types of VTs - text and graphical. It is only practical to have a single graphical VT because of the complexity of state swapping a graphical VT at VT swap. Right now we can all-ready run X on multiple VTs and with DRI-reinit can run GL apps on all of them. It may noy be the most elegant thing but it workes. We need the OS to keep state, even graphical, GART and all. I don't see how a 128M GART is diffrent then 2Gb system memory. Should we have GART swap space on the HD, a GART partition? I'm for making the OS VT swap multiheaded DR?I? setups at whatever cost. An elegant implementation would not swap the entire GART at VT switches but only present the new VT framebuffer as new display on the screen while maintaining the AGP states. Check out e.g. MacOS-X's animated multiple login screen: At every new session start the current session just rotates smoothly animated into the background and a new one is brought up. In this model you can retain the entire graphics state at VT switch, only another (currently invisible) frambuffer/screen/display/VT is made visible. This allows straightforward multihead implementations, any frambuffer/screen/display/VT can get attached to any head, they are just a piece of framebuffer memory which is either located in graphics memory or system memory and can get relocated on request, even to other graphics cards. How about this for a new way to look at the problem? System based xterm, that's a new one. I don't see how it's better then what we have now. probably not -- the MacOS-X alike approach looks more promising. At SAK a new display framebuffer would get launched and brought to front, the currently running application is only need get killed if it locks the graphics engine in an locked state. Unfortunally that means that parts of the window stack implementation need to run in kernel space (or a tightly connected trusted agent in userspace). Don't know whether this is a problem, the DirectFB core showed that it's possible to implement this cleanly in a few thousand lines of code. Holger __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Yes the GART swap, if it needs to be done with memcpys, should be posponed untill the user has SOME type of interface. Thats the important thing, allowing the user to interact is above hardware based rendering. I never liked the way GLapps froze when they where not on the current VT. I think the answer too these problems is runnaway rendering, where the openGL calls simply return as thought they didn't do any thing. --- Holger Waechtler [EMAIL PROTECTED] wrote: Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: There are two types of VTs - text and graphical. It is only practical to have a single graphical VT because of the complexity of state swapping a graphical VT at VT swap. Right now we can all-ready run X on multiple VTs and with DRI-reinit can run GL apps on all of them. It may noy be the most elegant thing but it workes. We need the OS to keep state, even graphical, GART and all. I don't see how a 128M GART is diffrent then 2Gb system memory. Should we have GART swap space on the HD, a GART partition? I'm for making the OS VT swap multiheaded DR?I? setups at whatever cost. An elegant implementation would not swap the entire GART at VT switches but only present the new VT framebuffer as new display on the screen while maintaining the AGP states. Check out e.g. MacOS-X's animated multiple login screen: At every new session start the current session just rotates smoothly animated into the background and a new one is brought up. In this model you can retain the entire graphics state at VT switch, only another (currently invisible) frambuffer/screen/display/VT is made visible. This allows straightforward multihead implementations, any frambuffer/screen/display/VT can get attached to any head, they are just a piece of framebuffer memory which is either located in graphics memory or system memory and can get relocated on request, even to other graphics cards. How about this for a new way to look at the problem? System based xterm, that's a new one. I don't see how it's better then what we have now. probably not -- the MacOS-X alike approach looks more promising. At SAK a new display framebuffer would get launched and brought to front, the currently running application is only need get killed if it locks the graphics engine in an locked state. Unfortunally that means that parts of the window stack implementation need to run in kernel space (or a tightly connected trusted agent in userspace). Don't know whether this is a problem, the DirectFB core showed that it's possible to implement this cleanly in a few thousand lines of code. Holger __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Some questions regarding locks
Lets just say that this is good fault tolorance. What ever can go wrong will, all drivers are faulty. This sounds like a good idea and should be implemented for ordinary use or something like it. Unless you thing we should KP on a lock being held for more then a given time(30 seconds)? --- Keith Whitwell [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking whether the caller actually holds the global lock. There is no LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has no check in it either. Did I miss something, or is this intended behaviour? It certainly seems strange to me. Also, it is possible for a DRI client to effectively lock up the entire machine simply by entering an endless loop after taking the lock. I suppose one could still log in remotely and kill the offending process, but that's not a realistic option for most people. Switching to a different VT or killing the X server does not work, because the X server has to take the DRI lock in the process. This is a problem that I want to fix (it makes playing around with the R300 hack Vladimir Dergachev posted an infinite-rebooting nightmare), but I am unsure what the best solution would be. If you're looking for ways to deal with debugging unstable drivers, I'm sorry but there's nothing that's going to come close to using two machines - one to do all your development, etc. on, and the other to continually reboot, crash, etc. as your test box. Keith __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Some questions regarding locks
Mike Mestnik wrote: Lets just say that this is good fault tolorance. What ever can go wrong will, all drivers are faulty. This sounds like a good idea and should be implemented for ordinary use or something like it. Unless you thing we should KP on a lock being held for more then a given time(30 seconds)? As a side note - when debugging a driver (eg singlestepping in gdb), I regularly hold the lock for longer than that. Also, when the VT is switched away from the X server, I believe that the hardware lock remains grabbed - for minutes or hours at a time. Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Some questions regarding locks
--- Keith Whitwell [EMAIL PROTECTED] wrote: Mike Mestnik wrote: Lets just say that this is good fault tolorance. What ever can go wrong will, all drivers are faulty. This sounds like a good idea and should be implemented for ordinary use or something like it. Unless you thing we should KP on a lock being held for more then a given time(30 seconds)? As a side note - when debugging a driver (eg singlestepping in gdb), I regularly hold the lock for longer than that. When debug is set we can turn these featurs off. Also, when the VT is switched away from the X server, I believe that the hardware lock remains grabbed - for minutes or hours at a time. This is a multi-user OS bug. I'l not even pretend it's a feature that we should keep. Keith __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texture units
On Fri, 21 May 2004 15:20:27 -0700 Mark Cass [EMAIL PROTECTED] wrote: guys, after reading documentation and looking in the code i noticed that the savage chip has two texture units. when does the second texture unit do its thing? i placed printfs in both sections of code (tex0 and tex1) and i only see the first unit doing anything. my test apps do not use multiple textures on a surface, is this what the second unit is for? Yes. The code in savagetex.c is pretty ugly at the moment. There are two separate functions to set the state of texture unit 0 and 1 respectively. They are mostly copy-paste. But some details WRT blending the two textures are different. BTW, only Savage4 and newer has 2 texture units. Savage3D/IX/MX has only one. mark | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Some questions regarding locks
Also, when the VT is switched away from the X server, I believe that the hardware lock remains grabbed - for minutes or hours at a time. This is a multi-user OS bug. I'l not even pretend it's a feature that we should keep. Just making you aware of the issues. Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
André Ventura Lemos wrote: Not at all... This only happens with 2.6 kernels. Prior do the lockup, everything works (I can see it through ssh), but the display gets blank, and never comes back. On Fri, 2004-05-21 at 18:07, Keith Whitwell wrote: Do you mind if I take this to dri-devel? What happens prior to the lockup? Does it only happen with 2.6 kernels? Keith Andre - Can you give any more information on what might be triggering the lockups? Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Development setup
Hello, I have just started looking into DRI development and I have been experiencing some difficulties using gdb. For example, I cannot currently step into functions of libGL (it was compiled with debug info and LD_LIBRARY_PATH is set correctly). Another thing is that the symbols from r200_dri.so are only loaded after I have typed sharedlibrary r200_dri, they're not loaded automatically when the shared object is loaded even though gdb's option (I forget its name) to autoload symbols is on. As I was struggling to put together a convenient setup for debugging it got me wondering how those of you who use gdb for debugging have things set up. I'm interested to know things like locations of compiled libs/executables wrt the system libs, environment variables, makefile/config modifications, etc. Maybe I can gather this information into a document on the Wiki later on. Thanks in advance, Maurice van der Pot. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Some questions regarding locks
On Sat, 2004-05-22 at 14:04, Nicolai Haehnle wrote: It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking whether the caller actually holds the global lock. There is no LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has no check in it either. Did I miss something, or is this intended behaviour? It certainly seems strange to me. True. Note that the lock ioctls are only used on contention, but still. Also, it is possible for a DRI client to effectively lock up the entire machine simply by entering an endless loop after taking the lock. I suppose one could still log in remotely and kill the offending process, but that's not a realistic option for most people. Switching to a different VT or killing the X server does not work, because the X server has to take the DRI lock in the process. This is a problem that I want to fix (it makes playing around with the R300 hack Vladimir Dergachev posted an infinite-rebooting nightmare), but I am unsure what the best solution would be. As far as I can see, the problem is two-fold: One, the X server must be able to break the lock, and two, it (or the DRM) must somehow disable the offending DRI client to prevent the problem from reoccurring. I think the simplest solution would look something like this: Whenever DRM(lock) is called by a privileged client (i.e. the X server), and it needs to sleep because the lock is held by an unprivileged client, a watchdog timer is started before we schedule. DRM(unlock) unconditionally stops this watchdog timer. When the watchdog timer fires, it releases the lock and/or kills the offending DRI client. Side question: Is killing the offending DRI client enough? When the process is killed, the /dev/drm fd is closed, which should automatically release the lock. On the other hand, I'm pretty sure that we can't just kill a process immediately (unfortunately, I'm not familiar with process handling in the kernel). What if, for some reason, the process is in a state where it can't be killed yet? We're screwed? :) This sounds like an idea for you to play with, but I'm afraid it won't be useful very often in my experience: * getting rid of the offending client doesn't help with a wedged chip (some way to recover from that would be nice...) * it doesn't help if the X server itself spins with the lock held I agree with Keith that it's always good to have a second machine to do serious driver hacking. Side question #2: Is it safe to release the DRM lock in the watchdog? There might be races where the offending DRI client is currently executing a DRM ioctl when the watchdog fires. Not sure, but this might not be a problem when just killing the offending process? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
MergedFrameBuffer: New meta-mode syntax needed.
I'm currently unable to define a clone mode where one screen is smaller then the other. My thoughts are 1024x768_1024x768 == 1024x768 vs 1024x768-1024x768. The problem I have is that my settup is lopsided, one monitor has better modes than the other. The *larger* monitor is on the right, thus making it the secondary for GL applications. Another fix would be to make the center be zero and every thing left(negitive singed) of that being larger(unsigned) then that on the right. What is needed is to run full-screen apps (1600x1200) on the right side with (1400x1050) only partaly(1600 - 2047 + 1400 = 953 unused columns) being used for hardware GL. This solution althought more correct is more tedious. Is any one interested in seeing this goin? __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Some questions regarding locks
Nicolai Haehnle wrote: I think the simplest solution would look something like this: Whenever DRM(lock) is called by a privileged client (i.e. the X server), and it needs to sleep because the lock is held by an unprivileged client, a watchdog timer is started before we schedule. DRM(unlock) unconditionally stops this watchdog timer. When the watchdog timer fires, it releases the lock and/or kills the offending DRI client. This sounds reasonable to me. This will help with /some/ buggy driver cases that end-users may see. Like Keith said, it won't help developers much. Like Michel said, it won't help at all when the chip is crashed. Unfortunately, that is the most common case where the lock is held for a long time. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: MergedFrameBuffer: New meta-mode syntax needed.
--- Mike Mestnik [EMAIL PROTECTED] wrote: I'm currently unable to define a clone mode where one screen is smaller then the other. My thoughts are 1024x768_1024x768 == 1024x768 vs 1024x768-1024x768. You can, but you can't mix and match multi-sized clone modes with multi-sized dualhead modes. I was thinking of doing something like: option metamodes 1024x768-800x600-clone 1024x768-800x600-left adding the orientation to the metamode and then removing the orientation option. they problem is you then need to add checks to make sure you have enough framebuffer for all of the modes listed and you might end up with some huge or weirdly sized virtual desktops. PLus it just adds to the confusion. I also wanted to keep consistency with other mergedfb drivers. The problem I have is that my settup is lopsided, one monitor has better modes than the other. The *larger* monitor is on the right, thus making it the secondary for GL applications. If you'd prefer it be on the left, you can always switch the orientation of the crtcs. in my set up, crtc2 is left of crtc1. the orientation of the crtcs doesn't really matter. Another fix would be to make the center be zero and every thing left(negitive singed) of that being larger(unsigned) then that on the right. What is needed is to run full-screen apps (1600x1200) on the right side with (1400x1050) only partaly(1600 - 2047 + 1400 = 953 unused columns) being used for hardware GL. This solution althought more correct is more tedious. This isn't really feasible from the 2d drivers perspective. you could move the start of the 3d viewport over so that its 0 would be on the right half of the framebuffer. Is any one interested in seeing this goin? If you are going to go through that effort, you might as well just solve the problem for real and have the 3d driver just iterate over each block of 2048x2048. see the dri-devel archives: 2048 limit code Alex __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Slides from WinHEC on Microsoft Avalon
The slides contain some pretty detailed information on composition and text formatting. You probably need to boot windows to see these... http://www.eightypercent.net/Archive/2004/05/18.html#a185 Greg Schecter: Avalon Graphics Stack Overview [682 KB] Joe Beda (me): Avalon Graphics - 2D, 3D, Imaging and Composition [284 KB] Kerry Hammil: Graphics on the Windows Desktop [496 KB] David Brown: Avalon Text [1.05 MB] = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
