[intel] How to turn off output from xorg.conf or force resolution?
I have recently purchased a Dell D430 with a WXGA matrix. At home I have a docking station connected to a Samsung LCD screen connected via DVI (TMDS-1 output), which I use only when needed. This LCD has a native resolution 1280x1024 and xrandr reports that it doesn't support 1280x800, which is the native resolution of the LVDS of my laptop. The problem is, that when I start my machine, The resolution on the LVDS is set to 1024x768, which is one of the resolutions supported by the external flat panel. So the picture on LVDS is occupies just a part of a screen. I can easily now switch to 1280x800 using xrandr, but I want do have it like this by default. Question: how to obtain it? How to tell X to set resolution which is native to LVDS, not to any connected external output (possible are VGA and TMDS-1). In my xorg.conf I've defined such sections, which are used by X. How should I change them? Section Monitor Identifier LVDS VendorName Built-in matrix Option DPMS yes EndSection Section Monitor Identifier TMDS-1 VendorName External monitor Option DPMS yes Option SameAs LVDS EndSection Section Monitor Identifier VGA VendorName External monitor Option DPMS yes Option SameAs LVDS EndSection -- Łukasz Maśko GG: 2441498_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające Nie umiem zainstalować Debiana ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: building of xrandr against uClibc
Adam Jackson a...@nwnk.net writes: On Tue, 2009-11-03 at 02:14 +0100, Stephan Raue wrote: Hi all, can anyone fix compiling of xrandr against uClibc (reported in http://bugs.freedesktop.org/show_bug.cgi?id=12958) see also: http://osdir.com/ml/linux.lfs.hardened/2008-04/msg9.html http://lists.x.org/archives/xorg-devel/2009-February/000281.html http://bugs.gentoo.org/197013 http://www.mail-archive.com/hlfs-...@linuxfromscratch.org/msg02003.html Pretty sure this is a uclibc header bug. glibc has exactly the same definitions in bits/sched.h and does not have this problem. Which I already said the last time this was brought up: http://lists.x.org/archives/xorg-devel/2009-March/000365.html - ajax If you think that it is a bug in the uclibc headers to declare the clone() function at all, your argument is valid. However, I think the comment in the bug (why cant this symbol get renamed so that things compile?) is also valid (regardless of who is at fault). Renaming the enum value to avoid the potential conflict may be the better option anyway... And I don't think glibc's behaviour is a normative reference :) (If someone could find a specification that clearly says whether it is disallowed to declare clone(), that would be nice...) eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: building of xrandr against uClibc
Eirik Byrkjeflot Anonsen schrieb: Adam Jackson a...@nwnk.net writes: On Tue, 2009-11-03 at 02:14 +0100, Stephan Raue wrote: Hi all, can anyone fix compiling of xrandr against uClibc (reported in http://bugs.freedesktop.org/show_bug.cgi?id=12958) see also: http://osdir.com/ml/linux.lfs.hardened/2008-04/msg9.html http://lists.x.org/archives/xorg-devel/2009-February/000281.html http://bugs.gentoo.org/197013 http://www.mail-archive.com/hlfs-...@linuxfromscratch.org/msg02003.html Pretty sure this is a uclibc header bug. glibc has exactly the same definitions in bits/sched.h and does not have this problem. Which I already said the last time this was brought up: http://lists.x.org/archives/xorg-devel/2009-March/000365.html - ajax If you think that it is a bug in the uclibc headers to declare the clone() function at all, your argument is valid. However, I think the comment in the bug (why cant this symbol get renamed so that things compile?) is also valid (regardless of who is at fault). Renaming the enum value to avoid the potential conflict may be the better option anyway... And I don't think glibc's behaviour is a normative reference :) (If someone could find a specification that clearly says whether it is disallowed to declare clone(), that would be nice...) I have no clue where clone is coming but you may like to know: glibc/linux also has a syscall called clone, who is that handled ? re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: building of xrandr against uClibc
Le mardi 03 novembre 2009 à 13:04 -0500, Adam Jackson a écrit : On Tue, 2009-11-03 at 02:14 +0100, Stephan Raue wrote: Hi all, can anyone fix compiling of xrandr against uClibc (reported in http://bugs.freedesktop.org/show_bug.cgi?id=12958) see also: http://osdir.com/ml/linux.lfs.hardened/2008-04/msg9.html http://lists.x.org/archives/xorg-devel/2009-February/000281.html http://bugs.gentoo.org/197013 http://www.mail-archive.com/hlfs-...@linuxfromscratch.org/msg02003.html Pretty sure this is a uclibc header bug. glibc has exactly the same definitions in bits/sched.h and does not have this problem. Which I already said the last time this was brought up: http://lists.x.org/archives/xorg-devel/2009-March/000365.html It's indeed a header bug. BTW, the policy variable is never really used in the code, it's only set while parsing for option, never read. So there's something wrong in the code. Regards. -- Yann Droneaud ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: building of xrandr against uClibc
Twas brillig at 13:04:37 03.11.2009 UTC-05 when a...@nwnk.net did gyre and
gimble:
AJ Pretty sure this is a uclibc header bug. glibc has exactly the
AJ same definitions in bits/sched.h and does not have this problem.
AJ Which I already said the last time this was brought up:
#include sched.h
typedef enum baz {
clone
} baz_baz;
does not compile.
Looks like in uClibc setup some of headers indirectly include sched.h
(I don't have working uClibc-based build environment right now to test
it).
Error can be easily reproduced with glibc by adding #include sched.h
to the xrandr.c
--
http://fossarchy.blogspot.com/
pgpOQxBPZhNHt.pgp
Description: PGP signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: building of xrandr against uClibc
walter harms wha...@bfs.de writes: Eirik Byrkjeflot Anonsen schrieb: Adam Jackson a...@nwnk.net writes: On Tue, 2009-11-03 at 02:14 +0100, Stephan Raue wrote: Hi all, can anyone fix compiling of xrandr against uClibc (reported in http://bugs.freedesktop.org/show_bug.cgi?id=12958) see also: http://osdir.com/ml/linux.lfs.hardened/2008-04/msg9.html http://lists.x.org/archives/xorg-devel/2009-February/000281.html http://bugs.gentoo.org/197013 http://www.mail-archive.com/hlfs-...@linuxfromscratch.org/msg02003.html Pretty sure this is a uclibc header bug. glibc has exactly the same definitions in bits/sched.h and does not have this problem. Which I already said the last time this was brought up: http://lists.x.org/archives/xorg-devel/2009-March/000365.html - ajax If you think that it is a bug in the uclibc headers to declare the clone() function at all, your argument is valid. However, I think the comment in the bug (why cant this symbol get renamed so that things compile?) is also valid (regardless of who is at fault). Renaming the enum value to avoid the potential conflict may be the better option anyway... And I don't think glibc's behaviour is a normative reference :) (If someone could find a specification that clearly says whether it is disallowed to declare clone(), that would be nice...) I have no clue where clone is coming but you may like to know: glibc/linux also has a syscall called clone, who is that handled ? Two possibilities: 1: The relevant header file does not get included when using glibc. 2: glibc only declares this function if requested. The man page seems to indicate that 2 is true (You need to #define _GNU_SOURCE). But Mikhail's response indicates that 1 is true. eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: configure xorg for flat panel
PJ wrote: Somehow, the web does show there are problems setting up flat panels but I have found no solutions. FreeBSD 7.2, Xorg 1.6 something - it's the latest for FBSD, driver is nv (Nvidia) FX5600, the monitor is LG W2361. I cannot find any errors in /var/log/Xorg.0.log # Xorg -config xorg.conf.new produces only a black screen regardless of what mouse I may be using - the mouse setup is always auto and sysmouse - the log shows Silkenmouse enabled (At the moment it is an IBM usb with button (cute blue) :-) the keyboard - same stuff: specify an us,ca keyboard or leave it as default... Same for the mode of the monitor same non-functionality as DVI or as DSUB - digital or analog. AllowEmptyInput off only prevents getting out of the test mode - even ctl/Alt/Del does not respond. The log shows that the monitor is being detected correctly; the parameters for the monitor are displayed correctly... but there is no mouse, no keyboard, no image DontZap has no discernible effect. hal is on I have no problems with Xorg on this machine or another with analog monitors. All work just fine. Xorg just plain refuses to start... yet the monitor works fine on XP as digital or analog and works in dual mode with another analog monitor. And, yes I did read the manual and did try various options suggested on the web So what's the story here? I tried to avoid bothering the list, but this is getting a little ridiculous. Oh, yes, at one point when shutting down with ctl/alt/del there was a very clear X in the middle of the screen - but it would not move and then the machine rebooted. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I see no one seems to know anything about flat panels on Xorg. Well, I did get it up and running, but no thanks to any information in either the xorg or freebsd manuals... I accidentally ran startx and to my great surprise the screen came up with fluxbox and did work, albeit very sporadically... it kept going black and sort-of flickered. I shutdown and checked the log and lo and behold, the configuration file was one I had forgotten about that came from another computer from where the current disk was cloned. So, with a little tweaking, the thing now works - but the what and the why excape me completely. The configurations does not need any parameters for horiz or vertical scanning - only the screen depth and monitor size. I guess the name of the manufacturer and the model are irrelevant. Oh yes, the AllowEmptyInput had to be off ; the DontZap was also off Setting the FlatPanel settings (3 of them) to True does not seem to make any difference whether they are T of F. So, although it now works, configuration is still a total mystery. Does anyone understand just what is going on or are we just groping in the dark along with our blind leaders? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xrandr: Disable --clone / --extend support code.
This was dead code after all.
The usage message regarding those options was already commented out.
This could be a fix for bug #12958
---
xrandr.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index f7eba11..242ed06 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -210,9 +210,11 @@ reflection_name (Rotation rotation)
}
#if HAS_RANDR_1_2
+#if 0
typedef enum _policy {
clone, extend
} policy_t;
+#endif
typedef enum _relation {
left_of, right_of, above, below, same_as,
@@ -2062,7 +2064,9 @@ main (int argc, char **argv)
intret = 0;
#if HAS_RANDR_1_2
output_t *output = NULL;
+#if 0
policy_t policy = clone;
+#endif
Bool setit_1_2 = False;
Bool query_1_2 = False;
Bool modeit = False;
@@ -2436,6 +2440,7 @@ main (int argc, char **argv)
setit_1_2 = True;
continue;
}
+#if 0
if (!strcmp (--clone, argv[i])) {
policy = clone;
setit_1_2 = True;
@@ -2446,6 +2451,7 @@ main (int argc, char **argv)
setit_1_2 = True;
continue;
}
+#endif
if (!strcmp (--auto, argv[i])) {
if (output)
{
--
1.6.0.2
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xrandr: Remove test against RANDR_MAJOR/RANDR_MINOR, already done by configure script
Le 04/11/2009 14:28, Yann Droneaud a écrit : xrandr.c uses structures defined inX11/extensions/Xrandr.h provided by 'libXrandr' package but tests structures availability through RANDR_MAJOR/RANDR_MINOR defined inX11/extensions/randr.h provided by 'randrproto' package. Sometimes they are not in sync so it's safer to rely on checks made by configure script through pkg-config. In my test case, XRRPanning structure is not defined in Xrandr.h, RANDR_MAJOR is 1 and RANDR_MINOR 2 but xrandr.c try to use it anyway. (for the record, XRRPanning was added in libXrandr-1.2.91). configure.ac deps on xrandr = 1.3. Reviewed-by: Rémi Cardona r...@gentoo.org I'll push it to master in a few days if no-one objects. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: configure xorg for flat panel
Alex Deucher wrote: On Wed, Nov 4, 2009 at 7:10 AM, PJ af.gour...@videotron.ca wrote: PJ wrote: Somehow, the web does show there are problems setting up flat panels but I have found no solutions. FreeBSD 7.2, Xorg 1.6 something - it's the latest for FBSD, driver is nv (Nvidia) FX5600, the monitor is LG W2361. I cannot find any errors in /var/log/Xorg.0.log # Xorg -config xorg.conf.new produces only a black screen regardless of what mouse I may be using - the mouse setup is always auto and sysmouse - the log shows Silkenmouse enabled (At the moment it is an IBM usb with button (cute blue) :-) the keyboard - same stuff: specify an us,ca keyboard or leave it as default... Same for the mode of the monitor same non-functionality as DVI or as DSUB - digital or analog. AllowEmptyInput off only prevents getting out of the test mode - even ctl/Alt/Del does not respond. The log shows that the monitor is being detected correctly; the parameters for the monitor are displayed correctly... but there is no mouse, no keyboard, no image DontZap has no discernible effect. hal is on I have no problems with Xorg on this machine or another with analog monitors. All work just fine. Xorg just plain refuses to start... yet the monitor works fine on XP as digital or analog and works in dual mode with another analog monitor. And, yes I did read the manual and did try various options suggested on the web So what's the story here? I tried to avoid bothering the list, but this is getting a little ridiculous. Oh, yes, at one point when shutting down with ctl/alt/del there was a very clear X in the middle of the screen - but it would not move and then the machine rebooted. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I see no one seems to know anything about flat panels on Xorg. Well, I did get it up and running, but no thanks to any information in either the xorg or freebsd manuals... I accidentally ran startx and to my great surprise the screen came up with fluxbox and did work, albeit very sporadically... it kept going black and sort-of flickered. I shutdown and checked the log and lo and behold, the configuration file was one I had forgotten about that came from another computer from where the current disk was cloned. So, with a little tweaking, the thing now works - but the what and the why excape me completely. The configurations does not need any parameters for horiz or vertical scanning - only the screen depth and monitor size. I guess the name of the manufacturer and the model are irrelevant. Oh yes, the AllowEmptyInput had to be off ; �the DontZap was also off Setting the FlatPanel settings (3 of them) to True does not seem to make any difference whether they are T of F. So, although it now works, configuration is still a total mystery. Does anyone understand just what is going on or are we just groping in the dark along with our blind leaders? Most drivers get the modes out of the edid provided by the monitor. Digital monitors tend to be very picky about the timing they get, so if the mode info you were providing was different than that preferred modes in the edid, that would explain the problems. Actually, I did provide timing that was supposed to be supported according to what was probed by FreeBSD or was it Xorg... But this does not explain why hal did not function correctly... as far as I can see, hal is a piece of crap. It has never fuctioned on any of my installations, and there have been several. I really am offended for being taken as a guinea pig for some greenhorn programmers who don't have common sense. So far, it looks like the only way to get things running with Xorg is by blind man's bluff - grope and poke and hope something works. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: configure xorg for flat panel
On Wed, Nov 4, 2009 at 3:29 PM, PJ af.gour...@videotron.ca wrote: Alex Deucher wrote: On Wed, Nov 4, 2009 at 7:10 AM, PJ af.gour...@videotron.ca wrote: PJ wrote: Somehow, the web does show there are problems setting up flat panels but I have found no solutions. FreeBSD 7.2, Xorg 1.6 something - it's the latest for FBSD, driver is nv (Nvidia) FX5600, the monitor is LG W2361. I cannot find any errors in /var/log/Xorg.0.log # Xorg -config xorg.conf.new produces only a black screen regardless of what mouse I may be using - the mouse setup is always auto and sysmouse - the log shows Silkenmouse enabled (At the moment it is an IBM usb with button (cute blue) :-) the keyboard - same stuff: specify an us,ca keyboard or leave it as default... Same for the mode of the monitor same non-functionality as DVI or as DSUB - digital or analog. AllowEmptyInput off only prevents getting out of the test mode - even ctl/Alt/Del does not respond. The log shows that the monitor is being detected correctly; the parameters for the monitor are displayed correctly... but there is no mouse, no keyboard, no image DontZap has no discernible effect. hal is on I have no problems with Xorg on this machine or another with analog monitors. All work just fine. Xorg just plain refuses to start... yet the monitor works fine on XP as digital or analog and works in dual mode with another analog monitor. And, yes I did read the manual and did try various options suggested on the web So what's the story here? I tried to avoid bothering the list, but this is getting a little ridiculous. Oh, yes, at one point when shutting down with ctl/alt/del there was a very clear X in the middle of the screen - but it would not move and then the machine rebooted. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I see no one seems to know anything about flat panels on Xorg. Well, I did get it up and running, but no thanks to any information in either the xorg or freebsd manuals... I accidentally ran startx and to my great surprise the screen came up with fluxbox and did work, albeit very sporadically... it kept going black and sort-of flickered. I shutdown and checked the log and lo and behold, the configuration file was one I had forgotten about that came from another computer from where the current disk was cloned. So, with a little tweaking, the thing now works - but the what and the why excape me completely. The configurations does not need any parameters for horiz or vertical scanning - only the screen depth and monitor size. I guess the name of the manufacturer and the model are irrelevant. Oh yes, the AllowEmptyInput had to be off ; �the DontZap was also off Setting the FlatPanel settings (3 of them) to True does not seem to make any difference whether they are T of F. So, although it now works, configuration is still a total mystery. Does anyone understand just what is going on or are we just groping in the dark along with our blind leaders? Most drivers get the modes out of the edid provided by the monitor. Digital monitors tend to be very picky about the timing they get, so if the mode info you were providing was different than that preferred modes in the edid, that would explain the problems. Actually, I did provide timing that was supposed to be supported according to what was probed by FreeBSD or was it Xorg... But this does not explain why hal did not function correctly... as far as I can see, hal is a piece of crap. It has never fuctioned on any of my installations, and there have been several. I really am offended for being taken as a guinea pig for some greenhorn programmers who don't have common sense. So far, it looks like the only way to get things running with Xorg is by blind man's bluff - grope and poke and hope something works. HAL doesn't do anything WRT to the video driver. Your best bet is to not use a config file and to let the driver probe the hardware directly. User intervention generally causes problems as was the case in your situation. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
