Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
I am the tech guy for a local library. We have a network containing several diskless workstations. The hardware are these P4 boxes: http://www.geeks.com/details.asp?invtid=SAMBA845V-24-4-Rcat=SYS (We have inserted additional memory, bringing most of the machines up to 1.25Gig of memory, and two up to 2Gig of memory.) These little machines have integrated Intel video chips on their motherboards and have both VGA and DVI connectors: (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Integrated Graphics Chipset: Intel(R) 845G (--) I810(0): Chipset: 845G And the i810 driver seems to be happy to talk to these chips. I am using the stock (distro supplied) RPM: xorg-x11-drv-i810-1.6.5-9.40.el5 The machines are running pretty much stock CentOS 5.8 (I am slightly behind on some updates). These machine boot off the network and then mount their root (/), /usr, and /home file systems via NFS from the server and function otherwise as normal workstations. And they work great with 4:3 monitors. Recently, because of new cataloging and circulation software which seems to have been designed by (open source) developers who probably have new widescreen monitors on their machines, we have put widescreen (16:9) monitors on three of the machines (various menus and toolbars don't fit on a 4:3 monitor, even at 1280x1024 [19-20 monitor]). But we are having some problems getting the proper aspect ratio (or even a display at all) on two of the three. First of all, using the VGA connection, the X server *refuses* to use any Modeline that is not a 4:3 aspect ratio. It seems that the X server presumes that *all* VGA connected monitors are 4:3. (All three of the new wide screen monitors do have 15-pin VGA connections, so this 'presumption' is obviously false, esp. since the monitors using DDC while connection via VGA are suggesting 16:9 mode lines.) I got *one* of the machines to correctly use a 16:9 aspect ratio Modeline (1600x900) using the DVI connection. The other two don't work. One won't display anything (claims that the video is missing or wrong). And the other just uses something like 640x480. Both monitors work just fine on DVI in console display mode (bare kernel VGA), so the video card is seeing the monitor and sending it a signal at that level. I have tried everything I can think of. The various log files and config files are here (each tar file contains one log and one config): This is the *working* machine (HP W2072a): http://www.deepsoft.com/wp-content/uploads/2012/09/catalog-DVI-1600x900.tar.gz These are for a (not working) Acer X223W: http://www.deepsoft.com/wp-content/uploads/2012/09/clearwater-VGA.tar.gz http://www.deepsoft.com/wp-content/uploads/2012/09/clearwater-DVI.tar.gz From xdpyinfo while connection via VGA: screen #0: dimensions:1680x1200 pixels (474x302 millimeters) resolution:90x101 dots per inch And for a (not working) ViewSonic VA2431WM: http://www.deepsoft.com/wp-content/uploads/2012/09/circdesk-VGA.tar.gz http://www.deepsoft.com/wp-content/uploads/2012/09/circdesk-DVI-1600x900.tar.gz http://www.deepsoft.com/wp-content/uploads/2012/09/circdesk-DVI-1440x900.tar.gz http://www.deepsoft.com/wp-content/uploads/2012/09/circdesk-DVI.tar.gz From xdpyinfo while connection via VGA: screen #0: dimensions:1600x1200 pixels (521x290 millimeters) resolution:78x105 dots per inch We would really like square pixels -- is it possible or not? -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
On 9/22/12 5:55 PM, Robert Heller wrote: First of all, using the VGA connection, the X server *refuses* to use any Modeline that is not a 4:3 aspect ratio. It seems that the X server presumes that *all* VGA connected monitors are 4:3. (All three of the new wide screen monitors do have 15-pin VGA connections, so this 'presumption' is obviously false, esp. since the monitors using DDC while connection via VGA are suggesting 16:9 mode lines.) It's not the X server's fault. The i810 driver, when it comes to output setup, is no better than the vesa driver. It can only set modes that happen to be listed in the video BIOS, regardless of what the display happens to claim to support. Since most 845 video BIOSes predate the wide availability of 16:9 monitors, they naturally tend not to list any 16:9 modes. RHEL5 (and therefore CentOS 5) does include an additional video driver for Intel graphics chips called 'intel' instead of 'i810', which does not have this limitation. I don't recall offhand whether that version worked correctly with 8xx-series chips; it might, I don't think I went out of my way to disable that, but if it doesn't work you get to keep both pieces. Alternatively, go search for 'i915resolution', which will allow you to override Intel VBIOS mode lists (and yes it does work on 8xx chips despite the name). - ajax ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
On 2012-09-22 20:01 (GMT-0400) Felix Miata composed: On 2012-09-22 17:55 (GMT-0400) Robert Heller composed: I am the tech guy for a local library... (II) I810(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Integrated Graphics Chipset: Intel(R) 845G (--) I810(0): Chipset: 845G... The 845G has been a troublesome video chip, probably the worst widely used chip: https://bugs.freedesktop.org/show_bug.cgi?id=26345 https://qa.mandriva.com/show_bug.cgi?id=62960 https://bugzilla.redhat.com/show_bug.cgi?id=692293 https://bugzilla.novell.com/show_bug.cgi?id=709863 http://bugs.centos.org/view.php?id=1594 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/930553 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-driver-nv/+bug/455084 Looking through those bugs you might find a clue to a solution. I have two working 845G systems, but I don't try to use them with non-4:3 displays or with CentOS, so there's probably little more help I can give given what Adam Jackson already wrote in thread. Most of the 845G systems I've run across include AGP slots. Dell equipped many of its 845G Optiplex machines with Radeon 7500 AGP cards. There are many cheap new and used AGP cards around that do support widescreen modes, e.g. http://www.geeks.com/details.asp?invtid=9250-AGP-128-PBcat=VCD http://www.ebay.com/itm/ATI-Technologies-ATI-Radeon-7500-100-711014-64-MB-DDR-SDRAM-AGP-4x-Graphics-/140851713660?pt=PCC_Video_TV_Cardshash=item20cb6a967c http://www.ebay.com/itm/Sapphire-Technology-ATI-Radeon-9250-100582-128-MB-DDR-SDRAM-AGP-8x-Graphics-/140852649792?pt=PCC_Video_TV_Cardshash=item20cb78df40 BTW, installing an AGP card constitutes a RAM upgrade, as 845G chips use/share main motherboard RAM. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
On 2012-09-22 23:33 (GMT-0400) Robert Heller composed: These boxes are small form factor machines and only have two PCI slots on a riser card. No AGP slots, so no option of alternitive video cards, unless with use PCI video cards (are such cards even available?). http://www.ebay.com/itm/New-ATI-Radeon-9200-Features-Up-to-128MB-of-DDR-PCI-Graphics-Card-/230805145505?forcev4exp=trueforceRpt=true http://www.ebay.com/itm/Diamond-Multimedia-ATI-Radeon-9200SE-128MB-DDR-PCI-graphics-card-DVI-VGA-/280952813779?pt=PCC_Video_TV_Cardshash=item416a17b8d3 They do, but whether they're new enough to support 16:9 modes other than 1920x1080, if that, may take some digging to find out. 1920x1080 as a HDTV standard mode is actually quite old, while newer 1280x800, 1366x768, 1440x900, 1600x900 1680x1050 modes require newer chips to provide required video BIOS mode support. New PCI cards still are made, but could well be cost ineffective for your situation. It might be significantly cheaper to trade out those widescreens for widely available though sometimes tricky to locate 1280x1024s, if you can't make those 845Gs do what you need. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH 2/3] os: refactor timer processing
Combine two open coded loops that do the same thing:
Call DoTimer() for all expired timers
Signed-off-by: Daniel Kurtz djku...@chromium.org
---
os/WaitFor.c | 68 +
1 files changed, 30 insertions(+), 38 deletions(-)
diff --git a/os/WaitFor.c b/os/WaitFor.c
index 8630fc9..2aab6d1 100644
--- a/os/WaitFor.c
+++ b/os/WaitFor.c
@@ -121,6 +121,7 @@ struct _OsTimerRec {
};
static void DoTimer(OsTimerPtr timer, CARD32 now, OsTimerPtr *prev);
+static Bool DoTimers(void);
static void CheckAllTimers(void);
volatile static OsTimerPtr timers = NULL;
@@ -250,49 +251,14 @@ WaitForSomething(int *pClientsReady)
XFD_COPYSET(ClientsWithInput, clientsReadable);
break;
}
-if (*checkForInput[0] != *checkForInput[1])
+if (*checkForInput[0] != *checkForInput[1] || DoTimers())
return 0;
-
-OsBlockSignals();
-if (timers) {
-int expired = 0;
-
-now = GetTimeInMillis();
-if ((int) (timers-expires - now) = 0)
-expired = 1;
-
-while (timers (int) (timers-expires - now) = 0)
-DoTimer(timers, now, timers);
-
-if (expired) {
-OsReleaseSignals();
-return 0;
-}
-}
-OsReleaseSignals();
}
else {
fd_set tmp_set;
-if (*checkForInput[0] == *checkForInput[1]) {
-OsBlockSignals();
-if (timers) {
-int expired = 0;
-
-now = GetTimeInMillis();
-if ((int) (timers-expires - now) = 0)
-expired = 1;
-
-while (timers (int) (timers-expires - now) = 0)
-DoTimer(timers, now, timers);
-
-if (expired) {
-OsReleaseSignals();
-return 0;
-}
-}
-OsReleaseSignals();
-}
+if (*checkForInput[0] == *checkForInput[1] DoTimers())
+return 0;
if (someReady)
XFD_ORSET(LastSelectMask, ClientsWithInput, LastSelectMask);
if (AnyClientsWriteBlocked XFD_ANYSET(clientsWritable)) {
@@ -415,6 +381,32 @@ DoTimer(OsTimerPtr timer, CARD32 now, OsTimerPtr *prev)
TimerSet(timer, 0, newTime, timer-callback, timer-arg);
}
+/* Call DoTimer() for all expired timers.
+ * Returns TRUE if there were any expired timers
+ */
+static Bool
+DoTimers(void)
+{
+Bool expired = FALSE;
+CARD32 now;
+
+OsBlockSignals();
+if (!timers)
+goto out;
+
+now = GetTimeInMillis();
+if ((int) (timers-expires - now) 0)
+goto out;
+
+expired = TRUE;
+while (timers (int) (timers-expires - now) = 0)
+DoTimer(timers, now, timers);
+
+ out:
+OsReleaseSignals();
+return expired;
+}
+
OsTimerPtr
TimerSet(OsTimerPtr timer, int flags, CARD32 millis,
OsTimerCallback func, pointer arg)
--
1.7.7.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/3] os: refactor CheckAllTimers
CheckAllTimers() is called with signals blocked.
Calling TimerForce within CheckAllTimers is inefficient because:
(a) signals are be blocked unblocked again
(b) the timer list is traversed again
(c) CheckAllTimers() ignores the return value
Instead, just call DoTimer() directly.
Signed-off-by: Daniel Kurtz djku...@chromium.org
---
os/WaitFor.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/os/WaitFor.c b/os/WaitFor.c
index 2aab6d1..23347ec 100644
--- a/os/WaitFor.c
+++ b/os/WaitFor.c
@@ -355,15 +355,17 @@ WaitForSomething(int *pClientsReady)
static void
CheckAllTimers(void)
{
+OsTimerPtr *prev;
OsTimerPtr timer;
CARD32 now;
start:
now = GetTimeInMillis();
-for (timer = timers; timer; timer = timer-next) {
+for (prev = timers; *prev; prev = (*prev)-next) {
+timer = *prev;
if (timer-expires - now timer-delta + 250) {
-TimerForce(timer);
+DoTimer(timer, now, prev);
goto start;
}
}
--
1.7.7.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 0/3] Make timers even more resistant to signals
X Input drivers, such as xf86-input-synaptics, tend to do all of their processing in a SIGIO signal handler. This processing often involves creating, modifying or canceling a timer. Any of these operations may modify the global timers array. Therefore, all accesses of this global must be done in critical secitions during which signals are blocked. Otherwise, for example, a signal may clear the last timer between, which sets timers global to NULL, between the NULL check and checking expires, which causes a SEGV. A previous patch protected write accesses. However, this is not sufficient. Read accesses must also be protected from a signal occurring between when the timers is NULL checked and subsequent dereferences. This patchset also does some small clean up to the timer list processing. Although, the whole timer list should probably be rewritten someday using the more modern - and better tested - struct xorg_list... Daniel Kurtz (3): os: block signals when accessing global timer list os: refactor timer processing os: refactor CheckAllTimers os/WaitFor.c | 79 ++--- 1 files changed, 42 insertions(+), 37 deletions(-) -- 1.7.7.3 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/3] os: block signals when accessing global timer list
X Input drivers, such as xf86-input-synaptics, tend to do all of their
processing in a SIGIO signal handler. This processing often involves
creating, modifying or canceling a timer. Any of these operations may
modify the global timers array. Therefore, all accesses of this global
must be done in critical secitions during which signals are blocked.
Otherwise, for example, a signal may clear the last timer between, which
sets timers global to NULL, between the NULL check and checking expires,
which causes a SEGV.
A previous patch protected write accesses. However, this is not
sufficient. Read accesses must also be protected from a signal
occurring between when the timers is NULL checked and subsequent
dereferences.
The redundant signal blocking in DoTimer() and CheckAllTimers() is removed
since they are always called with signals already blocked.
Also, make the global |timers| volatile to ensure that the compiler does
not cache its value.
Signed-off-by: Daniel Kurtz djku...@chromium.org
---
os/WaitFor.c | 27 +++
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/os/WaitFor.c b/os/WaitFor.c
index 393890f..8630fc9 100644
--- a/os/WaitFor.c
+++ b/os/WaitFor.c
@@ -122,7 +122,7 @@ struct _OsTimerRec {
static void DoTimer(OsTimerPtr timer, CARD32 now, OsTimerPtr *prev);
static void CheckAllTimers(void);
-static OsTimerPtr timers = NULL;
+volatile static OsTimerPtr timers = NULL;
/*
* WaitForSomething:
@@ -186,6 +186,7 @@ WaitForSomething(int *pClientsReady)
}
else {
wt = NULL;
+OsBlockSignals();
if (timers) {
now = GetTimeInMillis();
timeout = timers-expires - now;
@@ -204,6 +205,7 @@ WaitForSomething(int *pClientsReady)
wt = waittime;
}
}
+OsReleaseSignals();
XFD_COPYSET(AllSockets, LastSelectMask);
}
@@ -251,6 +253,7 @@ WaitForSomething(int *pClientsReady)
if (*checkForInput[0] != *checkForInput[1])
return 0;
+OsBlockSignals();
if (timers) {
int expired = 0;
@@ -261,14 +264,18 @@ WaitForSomething(int *pClientsReady)
while (timers (int) (timers-expires - now) = 0)
DoTimer(timers, now, timers);
-if (expired)
+if (expired) {
+OsReleaseSignals();
return 0;
+}
}
+OsReleaseSignals();
}
else {
fd_set tmp_set;
if (*checkForInput[0] == *checkForInput[1]) {
+OsBlockSignals();
if (timers) {
int expired = 0;
@@ -279,9 +286,12 @@ WaitForSomething(int *pClientsReady)
while (timers (int) (timers-expires - now) = 0)
DoTimer(timers, now, timers);
-if (expired)
+if (expired) {
+OsReleaseSignals();
return 0;
+}
}
+OsReleaseSignals();
}
if (someReady)
XFD_ORSET(LastSelectMask, ClientsWithInput, LastSelectMask);
@@ -382,7 +392,6 @@ CheckAllTimers(void)
OsTimerPtr timer;
CARD32 now;
-OsBlockSignals();
start:
now = GetTimeInMillis();
@@ -392,7 +401,6 @@ CheckAllTimers(void)
goto start;
}
}
-OsReleaseSignals();
}
static void
@@ -400,13 +408,11 @@ DoTimer(OsTimerPtr timer, CARD32 now, OsTimerPtr *prev)
{
CARD32 newTime;
-OsBlockSignals();
*prev = timer-next;
timer-next = NULL;
newTime = (*timer-callback) (timer, now, timer-arg);
if (newTime)
TimerSet(timer, 0, newTime, timer-callback, timer-arg);
-OsReleaseSignals();
}
OsTimerPtr
@@ -508,10 +514,13 @@ TimerFree(OsTimerPtr timer)
void
TimerCheck(void)
{
-CARD32 now = GetTimeInMillis();
+CARD32 now;
+OsBlockSignals();
+now = GetTimeInMillis();
while (timers (int) (timers-expires - now) = 0)
DoTimer(timers, now, timers);
+OsReleaseSignals();
}
void
@@ -519,10 +528,12 @@ TimerInit(void)
{
OsTimerPtr timer;
+OsBlockSignals();
while ((timer = timers)) {
timers = timer-next;
free(timer);
}
+OsReleaseSignals();
}
#ifdef DPMSExtension
--
1.7.7.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 4/7] dix: Repack ClientRec
Adam Jackson a...@redhat.com writes: Pick smaller types where possible, including bitfielding some Bools and small enums, then shuffle the result to be hole-free. 192 - 128 bytes on LP64, 144 - 96 bytes on ILP32. One thing that would make this easier to check for 'optimal' packing would be to simply start with the largest sized objects and work down to the smallest ones. Otherwise, I'm sitting here counting bits. Or would that be less efficient at run time? -- keith.pack...@intel.com pgpvs57LPlaum.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: new xserver 1.13 stable branch maintainer
Matt Dew mar...@osource.org writes: Hi all, I've volunteered to drink from the fire hose and help out/take on xserver stable branch maintainer responsibilities from Jeremy for server Thanks, Matt! -- keith.pack...@intel.com pgpUtsozlLAVa.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure
https://bugs.freedesktop.org/show_bug.cgi?id=52952 --- Comment #11 from mypersonalmailb...@mail.com 2012-09-22 06:43:40 UTC --- (In reply to comment #10) try making the following change to radeon_combios_asic_init() in radeon_combios.c in the kernel. Remove the following code: /* DYN CLK 1 */ table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE); if (table) combios_parse_pll_table(dev, table); and see if that helps. I am not saying that I cannot do this, but I am not a Linux kernel developer, so I am not sure how I can make the change, and recompile the kernel. I do have Windows device driver development experience, but I have never done software development with Linux. Keeping that in mind, can you provide me with detailed instructions on how to make the edits and recompile the kernel? Regards, fpgahardwareengineer -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
