Re: nv driver obscurities...
On Sun, Nov 09, 2003 at 11:23:38AM -0800, Alex Deucher wrote: I agree that with hex values the driver is much harder to read and debug (as a casual developer). that's part of the reason the radeon driver is so well developed and feature-rich. however, I'd say that most drivers in xfree86 use hex values rather than symbolic names so symbolic names are hardly the norm. the nv driver is no more obscured than the trident or 3dlabs, etc. drivers. Have you looked at the glint driver ? All the register are accessed using nice named macros, taken out of the corresponding documentation. Or are you speaking about another 3dlabs driver i don't know about ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Sun, 9 Nov 2003, Alex Deucher wrote: I agree that with hex values the driver is much harder to read and debug (as a casual developer). that's part of the reason the radeon driver is so well developed and feature-rich. however, I'd say that most drivers in xfree86 use hex values rather than symbolic names so symbolic names are hardly the norm. the nv driver is no more obscured than the trident or 3dlabs, etc. drivers. I'm not trying to fix a bug in the trident or 3dlabs drivers however. However, if I were, I also don't have hardware specs for trident or 3dlabs hardware, and as such, symbolic names would be easier to deal with in both of those, or any other video drivers as well. A moot point however I suppose, as none of those drivers is ever likely to have any major work done on them in the future other than by their respective existing driver maintainers. Let's hope and pray that none of the existing maintainers gets hit by a bus, or we're screwed. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: devices Xfbdev
server is now 866KB, which is still a wee bit over what I'd expect.] DD I got about that for an IA32 build. So am I. Something happened, I used to get almost 100KB less than that. Unfortunately, I won't have time to track it down anytime soon. Anyone have time to try out Keith's tree on http://pdx.freedesktop.org/ ? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. Alex --- Sven Luther [EMAIL PROTECTED] wrote: On Sun, Nov 09, 2003 at 11:23:38AM -0800, Alex Deucher wrote: I agree that with hex values the driver is much harder to read and debug (as a casual developer). that's part of the reason the radeon driver is so well developed and feature-rich. however, I'd say that most drivers in xfree86 use hex values rather than symbolic names so symbolic names are hardly the norm. the nv driver is no more obscured than the trident or 3dlabs, etc. drivers. Have you looked at the glint driver ? All the register are accessed using nice named macros, taken out of the corresponding documentation. Or are you speaking about another 3dlabs driver i don't know about ? Friendly, Sven Luther __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
Some time ago, there was a chap in New Zealand who was attempting to reverse engineer and documaent what all the nvidia registers did, -plus get DMA going for various ops. Google may turn up something - I don't have a URL to hand. The last I heard came from a couple of years back however. Stephen -- Experience is the name everyone gives to their mistakes - Oscar Wilde ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Mon, 10 Nov 2003, Alex Deucher wrote: Date: Mon, 10 Nov 2003 06:38:24 -0800 (PST) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: nv driver obscurities... Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. That doesn't make it good practice. Symbolic names let people know what things are for, or provide clues at least. They also help to avoid many typo related problems. For example someone mistakenly saying 0x35c somewhere would much more easily go unnoticed than a symbolic name. That's why we have structured programming constructs such as macros to begin with - to make programming more readable and easier to understand. But obviously the point I'm trying to make is a debateable one, and I'm not going to change my mind on my thoughts regarding symbolic names, and I expect you and others aren't going to throw away years of programming and change your opinions either. We both now know what each other's opinions on the topic is, and that none of us are going to convince the other to change their opinion or their coding practices, so further discussion/debate is probably not useful as far as development is concerned. Let's just respectfully agree to disagree with each other on coding practice, and move on without further discussion. Thanks. Respectfully yours, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Mon, Nov 10, 2003 at 06:38:24AM -0800, Alex Deucher wrote: Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. Maybe the old 3dlabs XFree86 3.3 server was in this case, but the glint driver has had nice symbolic names since a long time. 3Dlabs is even quite free in releasing full NDAed documentation, unlike other companies. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
I agree with you that symbolic names are better in just about all respects. I'm just saying that the nv driver is not the only one that doesn't do it. That's it for me. Alex --- Mike A. Harris [EMAIL PROTECTED] wrote: On Mon, 10 Nov 2003, Alex Deucher wrote: Date: Mon, 10 Nov 2003 06:38:24 -0800 (PST) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: nv driver obscurities... Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. That doesn't make it good practice. Symbolic names let people know what things are for, or provide clues at least. They also help to avoid many typo related problems. For example someone mistakenly saying 0x35c somewhere would much more easily go unnoticed than a symbolic name. That's why we have structured programming constructs such as macros to begin with - to make programming more readable and easier to understand. But obviously the point I'm trying to make is a debateable one, and I'm not going to change my mind on my thoughts regarding symbolic names, and I expect you and others aren't going to throw away years of programming and change your opinions either. We both now know what each other's opinions on the topic is, and that none of us are going to convince the other to change their opinion or their coding practices, so further discussion/debate is probably not useful as far as development is concerned. Let's just respectfully agree to disagree with each other on coding practice, and move on without further discussion. Thanks. Respectfully yours, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 2D Acceleration not used using ATI Rage Mobility P/M AGP 2x
As I said, the CPU is normally idle. When I quickly drag windows on the screen using my mouse, the CPU gets maxed out. I cannot believe that the redraw speed is that slow regardless of themes and such: I can see the windows being actually redrawn on screen when I drag them around the screen. FYI: I'm using Red Hat 9 which ships with Gnome. This problem happens using Gnome and it is a general problem across all X applications. Salvio Marc Aurele La France wrote: On Sat, 8 Nov 2003, Marc Aurele La France wrote: On Fri, 7 Nov 2003, Salvio Sergi wrote: Everything starts fine with no errors (as you can see from the logs). The problem I have is that I don't think I have 2D acceleration. The simple test I do is to just drag a window on the screen... the redraw is extremely slow and the CPU is maxed out (only when I move the windows) This means (I guess) that I do not have 2D acceleration. Not necessarily. Use `top` is figure out which process is eating up CPU time. Replying to my own post, with a few more things to look into... If `top` shows that the server is not entirely to blame for the CPU load, see if turning on backing store has any effect. Is this a 3D app? If so, you're limited to software rendering (for now). BTW, your VideoRAM specification is irrelevent. The driver ignores it. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
glx failing
Hi all, with my current CVS snapshot (Changelog up to #530), glxgears gives me the following at startup: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 22 Current serial number in output stream: 23 This used to work before. I've seen this on both OS/2 and SuSE Linux 8.2 (XFree CVS built without DRI). Any idea what this means and/or where I should look? Thanks, Frank. -- Frank Giessler Klinikum der Universitaet Jena Tel.: +49-3641-9 32 57 80 Biomagnetisches Zentrum Fax : +49-3641-9 32 57 72 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 2D Acceleration not used using ATI Rage Mobility P/M AGP 2x
On Mon, 10 Nov 2003, Salvio wrote: Everything starts fine with no errors (as you can see from the logs). The problem I have is that I don't think I have 2D acceleration. The simple test I do is to just drag a window on the screen... the redraw is extremely slow and the CPU is maxed out (only when I move the windows) This means (I guess) that I do not have 2D acceleration. Not necessarily. Use `top` is figure out which process is eating up CPU time. Replying to my own post, with a few more things to look into... If `top` shows that the server is not entirely to blame for the CPU load, see if turning on backing store has any effect. Is this a 3D app? If so, you're limited to software rendering (for now). BTW, your VideoRAM specification is irrelevent. The driver ignores it. As I said, the CPU is normally idle. When I quickly drag windows on the screen using my mouse, the CPU gets maxed out. I cannot believe that the redraw speed is that slow regardless of themes and such: I can see the windows being actually redrawn on screen when I drag them around the screen. FYI: I'm using Red Hat 9 which ships with Gnome. This problem happens using Gnome and it is a general problem across all X applications. If you want help, stop wasting my time, and answer my questions. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glx failing
Frank Gießler wrote: with my current CVS snapshot (Changelog up to #530), glxgears gives me the following at startup: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 22 Current serial number in output stream: 23 This used to work before. I've seen this on both OS/2 and SuSE Linux 8.2 (XFree CVS built without DRI). Any idea what this means and/or where I should look? Can you give any details to help reproduce this error? There is a reported bug in this area, but I thought that it was fixed. Your XF86Config would also be useful. http://bugs.xfree86.org/show_bug.cgi?id=439 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: devices Xfbdev
On Mon, 2003-11-10 at 07:59, Juliusz Chroboczek wrote: server is now 866KB, which is still a wee bit over what I'd expect.] DD I got about that for an IA32 build. So am I. Something happened, I used to get almost 100KB less than that. Unfortunately, I won't have time to track it down anytime soon. Anyone have time to try out Keith's tree on http://pdx.freedesktop.org/ ? I built this from there about a week and a half ago, without any attempt to make it small (-Os optimization or uclibc or anything like that). -rwsr-xr-x1 root root 687576 Nov 1 03:28 /usr/X11R6/bin/Xfbdev signature.asc Description: This is a digitally signed message part
Re: 2D Acceleration not used using ATI Rage Mobility P/M AGP 2x
Marc, If `top` shows that the server is not entirely to blame for the CPU load, see if turning on backing store has any effect. CPU is idle - CPU is maxed out when moving windows swap memory is not used less than 50% of available phisical memory is used (both when moving and when not moving windows) Is this a 3D app? No. This happens with all X applcations. I'm testing using two XTerm windows and an empty desktop. what is the meaning of this? see if turning on backing store has any effect What else do you need to know? Salvio Marc Aurele La France wrote: On Mon, 10 Nov 2003, Salvio wrote: Everything starts fine with no errors (as you can see from the logs). The problem I have is that I don't think I have 2D acceleration. The simple test I do is to just drag a window on the screen... the redraw is extremely slow and the CPU is maxed out (only when I move the windows) This means (I guess) that I do not have 2D acceleration. Not necessarily. Use `top` is figure out which process is eating up CPU time. Replying to my own post, with a few more things to look into... If `top` shows that the server is not entirely to blame for the CPU load, see if turning on backing store has any effect. Is this a 3D app? If so, you're limited to software rendering (for now). BTW, your VideoRAM specification is irrelevent. The driver ignores it. As I said, the CPU is normally idle. When I quickly drag windows on the screen using my mouse, the CPU gets maxed out. I cannot believe that the redraw speed is that slow regardless of themes and such: I can see the windows being actually redrawn on screen when I drag them around the screen. FYI: I'm using Red Hat 9 which ships with Gnome. This problem happens using Gnome and it is a general problem across all X applications. If you want help, stop wasting my time, and answer my questions. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
in6addr_any reference breaks libICE.so compatibility
I've noticed that the reference to in6addr_any in xtrans has broken libICE.so compatibility, at least on FreeBSD 4.3. This shows up a runtime loader error when attempting to run applications built against an older version of the library: /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libICE.so.6: Undefined symbol in6addr_any It is almost certainly related to in6addr_any being a const. I'm not sure if this is a localised problem, or if it affects a wider range of platforms. I'm committing a workaround that makes use of IN6ADDR_ANY_INIT when available, and that works here. Has anyone seen this to be a problem on other platforms? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: in6addr_any reference breaks libICE.so compatibility
David Dawes wrote: I've noticed that the reference to in6addr_any in xtrans has broken libICE.so compatibility, at least on FreeBSD 4.3. This shows up a runtime loader error when attempting to run applications built against an older version of the library: /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libICE.so.6: Undefined symbol in6addr_any It is almost certainly related to in6addr_any being a const. I'm not sure if this is a localised problem, or if it affects a wider range of platforms. I'm committing a workaround that makes use of IN6ADDR_ANY_INIT when available, and that works here. Has anyone seen this to be a problem on other platforms? We have no problem like that on Solaris - but on Solaris in6addr_any is defined in libsocket.so, which libICE.so is linked with, so it always automatically gets resolved at runtime. I haven't seen any problem reports on other platforms either. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 2D Acceleration not used using ATI Rage Mobility P/M AGP 2x
On Mon, 10 Nov 2003, Salvio wrote: If `top` shows that the server is not entirely to blame for the CPU load, see if turning on backing store has any effect. CPU is idle - CPU is maxed out when moving windows swap memory is not used less than 50% of available phisical memory is used (both when moving and when not moving windows) You've said that already. But which process(es) is(are) eating CPU? The xterm, the Xserver, or some combination of both? Is this a 3D app? No. This happens with all X applcations. I'm testing using two XTerm windows and an empty desktop. OK. what is the meaning of this? see if turning on backing store has any effect Replace your XF86Config's videoRam line with Option BackingStore On. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: in6addr_any reference breaks libICE.so compatibility
On Mon, Nov 10, 2003 at 11:36:54AM -0800, Alan Coopersmith wrote: David Dawes wrote: I've noticed that the reference to in6addr_any in xtrans has broken libICE.so compatibility, at least on FreeBSD 4.3. This shows up a runtime loader error when attempting to run applications built against an older version of the library: /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libICE.so.6: Undefined symbol in6addr_any It is almost certainly related to in6addr_any being a const. I'm not sure if this is a localised problem, or if it affects a wider range of platforms. I'm committing a workaround that makes use of IN6ADDR_ANY_INIT when available, and that works here. Has anyone seen this to be a problem on other platforms? We have no problem like that on Solaris - but on Solaris in6addr_any is defined in libsocket.so, which libICE.so is linked with, so it always automatically gets resolved at runtime. I haven't seen any problem reports on other platforms either. On FreeBSD it is in libc.so. I thought that since 'cc' is used to create libICE.so, it was implicitly linked against -lc, based on the comment in bsdLib.rules: #ifndef BaseShLibReqs #define BaseShLibReqs /* -lc implied by $(CC) */ #endif If I add it explicitly it solves the problem. Maybe it needs to be added explicitly in OpenBSDLib.rules too? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 2D Acceleration not used using ATI Rage Mobility P/M AGP 2x
OK - thanks I'll have to try that on Friday (I won't be home before...) and will post the results. - Salvio Marc Aurele La France wrote: On Mon, 10 Nov 2003, Salvio wrote: If `top` shows that the server is not entirely to blame for the CPU load, see if turning on backing store has any effect. CPU is idle - CPU is maxed out when moving windows swap memory is not used less than 50% of available phisical memory is used (both when moving and when not moving windows) You've said that already. But which process(es) is(are) eating CPU? The xterm, the Xserver, or some combination of both? Is this a 3D app? No. This happens with all X applcations. I'm testing using two XTerm windows and an empty desktop. OK. what is the meaning of this? see if turning on backing store has any effect Replace your XF86Config's videoRam line with Option BackingStore On. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
rectangles in a region
hi all, is there any way to extract the XRectangles that make up a Region in Xlib? xlib ref doesn't mention anything to that effect. thanks, ricardo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XGetImage generates a BadAlloc error
ok... i should give up. that was it. I've been using Xlib for a few years now, and i've just learn that XSync and XFlush are actually very different. Thank you for your help, sorry for the noise... Pierre Mark Vojkovich wrote: XGetImage didn't generate the error, XCreatePixmap did. You are forgetting the client-server model. The server didn't get the CreatePixmap until you made your GetImage request, which would flush requests to the server (necessary since GetImage requires a reply from the server). Call XSync after your XCreatePixmap and you'll see it fail then. Mark. On Sat, 8 Nov 2003, Pierrot wrote: Hi all, I'm a newcomer to this list and my problem may be off topic. Anyway, running on Xfree 4.2.0, one of my applications (I mean the one I'm currently coding) is crashing with the following error: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 14967 Current serial number in output stream: 15016 But, after a bit of investigation, It seems that this error is generated by a call to XGetImage(), and not a XCreatePixmap() request. Actually any call to XGetImage in my application will generate a BadAlloc... And as far as I know, XGetImage should not generate a BadAlloc (according to the Xlib reference). So I would need so help and advice on this. Is this a known issue? Should I look a bit deeper into the XFree code to locate the exact error and why it is generated? Should I give up coding and stay away from computers for a while? Thank you in advance for any hint, Pierre ___ 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: rectangles in a region
On Mon, 10 Nov 2003, Ricardo A. Baratto wrote: hi all, is there any way to extract the XRectangles that make up a Region in Xlib? xlib ref doesn't mention anything to that effect. thanks, ricardo I don't see such a function. The Region is deliberately opaque too. You can see the internal format that XFree86 uses by looking at XFree86 source: http://cvsweb.xfree86.org/cvsweb/xc/lib/X11/region.h?rev=1.2content-type=text/x-cvsweb-markup but it's probably not wise to be assuming that all implementations are the same (I suspect they are, but they're not required to be). Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
DPMS should enable screen blanking
There's a report in bugzilla from Ed Fardos about problems that can happen
if DPMS is enabled (with xset) while the screen isn't blanked.
I can think of several ways to handle this. One is to force screen
blanking everwhere DPMSSet(level) with level != DPMSModeOn is
called. However, the easiest is probably to handle it in DPMSSet()
with something like this:
Index: xf86DPMS.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86DPMS.c,v
retrieving revision 1.10
diff -u -r1.10 xf86DPMS.c
--- xf86DPMS.c 17 Oct 2003 20:02:12 - 1.10
+++ xf86DPMS.c 11 Nov 2003 02:44:14 -
@@ -37,6 +37,8 @@
#include xf86.h
#include xf86Priv.h
#ifdef DPMSExtension
+#define DPMS_SERVER
+#include extensions/dpms.h
#include dpmsproc.h
#endif
@@ -140,6 +142,9 @@
if (DPMSIndex 0)
return;
+
+if (level != DPMSModeOn)
+ SaveScreens(SCREEN_SAVER_FORCER, ScreenSaverActive);
/* For each screen, set the DPMS level */
for (i = 0; i xf86NumScreens; i++) {
Since XFree86 is the only DDX in our source tree that implements DPMSSet(),
this would be the simplest way to do it pre-4.4.
Any comments?
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Re: devices Xfbdev
Hi Friends,
I am a bit confused ... I understand, if i crosscompiple(Xipaq) When we do make
World (I mean only the order of files)::
host.def - linux.cf - kdrive.cf - {xitsy.cf|tinyX.cf ; cross.def}
The file iPAQH3600.cf says define KDriveServer and XiPAQH3500Server in host.def, but
there is no conditional inclusion of iPAQH3600.cf in kdrive.cf (like its for tinyX.cf
and itsy.cf).
How wud this file(iPAQH3600.cf)get involved inthe process, if its not mentioned in
kdrive.cf? So... either this has to be _hardwired_ in the compilation process or WE
have put conditional inclusion entry in the kdrive.cf like ::
#if XiPAQH3500Server
#include iPAQH3600.cf
#endif
I think the latter case... what say, experts?
I wud like to write my complete cross-compilation experience ..if i get to know all
these detail... so that the _big_ guys wud have time to do more rewarding things than
answering new-bie questions like mine :)
Maybe thats the only way for me to express my gratitude.
Regards,
Jassi
