Re: vesa driver reports many modes, but only allows a few
On Thu, Mar 04, 2010 at 07:52:02AM -0600, Pat Kane wrote:
> Ross Boylan wrote:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x in ?? ()
>> (gdb) where
>> #0 0x in ?? ()
>> #1 0x0051a72a in DoConfigure ()
>> at ../../../../hw/xfree86/common/xf86Configure.c:832
>
> The traceback says that someone branched to zero at
> line 832 of hw/xfree86/common/xf86Configure.c, that
> section of code (from git master) looks like this:
>
> ConfiguredMonitor = NULL;
>
> xf86EnableAccess(xf86Screens[dev2screen[j]]);
> if ((*xf86Screens[dev2screen[j]]->PreInit)(xf86Screens[dev2screen[j]],
> 832: PROBE_DETECT) &&
> ConfiguredMonitor) {
> MonitorPtr = configureDDCMonitorSection(j);
> } else {
> MonitorPtr = configureMonitorSection(j);
> }
>
> So it appears that the expression:
> (*xf86Screens[dev2screen[j]]->PreInit)
> is NULL; it would be a good idea for that code to check
> if PreInit has been filled in before jumping through it.
>
> Can you recompile the X server with a test for NULL?
Er, if pScrn->PreInit is NULL, then something's gone quite seriously
wrong and we're screwed anyway.
Cheers,
Daniel
pgpVW1K0hDoUZ.pgp
Description: PGP signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: vesa driver reports many modes, but only allows a few
Here is an untest, not even compiled, patch to try:
diff --git a/hw/xfree86/common/xf86Configure.c
b/hw/xfree86/common/xf86Configure.c
index bce5aae..a8d8ef9 100644
--- a/hw/xfree86/common/xf86Configure.c
+++ b/hw/xfree86/common/xf86Configure.c
@@ -828,7 +828,9 @@ DoConfigure(void)
ConfiguredMonitor = NULL;
xf86EnableAccess(xf86Screens[dev2screen[j]]);
- if ((*xf86Screens[dev2screen[j]]->PreInit)(xf86Screens[dev2screen[j]],
+
+ if ((*xf86Screens[dev2screen[j]]->PreInit) &&
+ (*xf86Screens[dev2screen[j]]->PreInit)(xf86Screens[dev2screen[j]],
PROBE_DETECT) &&
ConfiguredMonitor) {
MonitorPtr = configureDDCMonitorSection(j);
Pat
---
On Thu, Mar 4, 2010 at 7:52 AM, Pat Kane wrote:
> Ross Boylan wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x in ?? ()
> > (gdb) where
> > #0 0x in ?? ()
> > #1 0x0051a72a in DoConfigure ()
> > at ../../../../hw/xfree86/common/xf86Configure.c:832
>
> The traceback says that someone branched to zero at
> line 832 of hw/xfree86/common/xf86Configure.c, that
> section of code (from git master) looks like this:
>
> ConfiguredMonitor = NULL;
>
> xf86EnableAccess(xf86Screens[dev2screen[j]]);
> if ((*xf86Screens[dev2screen[j]]->PreInit)(xf86Screens[dev2screen[j]],
> 832: PROBE_DETECT) &&
> ConfiguredMonitor) {
> MonitorPtr = configureDDCMonitorSection(j);
> } else {
> MonitorPtr = configureMonitorSection(j);
> }
>
> So it appears that the expression:
> (*xf86Screens[dev2screen[j]]->PreInit)
> is NULL; it would be a good idea for that code to check
> if PreInit has been filled in before jumping through it.
>
> Can you recompile the X server with a test for NULL?
>
> Pat
> ---
>
>
> On Wed, Mar 3, 2010 at 6:12 PM, Ross Boylan wrote:
>> On Wed, 2010-03-03 at 15:41 -0600, Pat Kane wrote:
>>> Could you run the configure under gdb to see if you get a better trace back?
>>>
>>> $gdb Xorg
>>> :r -configure
>>>
>>> could be some xemu hw emulated hw weirdness...
>>>
>> I also loaded some debug symbols.
>>
>> [tcsetpgrp failed in terminal_inferior: Operation not permitted]
>> (++) Using config file: "/root/xorg.conf.new"
>> (EE) open /dev/fb0: No such file or directory
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x in ?? ()
>> (gdb) where
>> #0 0x in ?? ()
>> #1 0x0051a72a in DoConfigure ()
>> at ../../../../hw/xfree86/common/xf86Configure.c:832
>> #2 0x00471c17 in InitOutput (pScreenInfo=0x7d5a80, argc=> optimized out>, argv=)
>> at ../../../../hw/xfree86/common/xf86Init.c:610
>> #3 0x00425a25 in main (argc=2, argv=0x7fffe258, envp=> optimized out>) at ../../dix/main.c:203
>>
>> Ross
>>
>>>
>>> On Tue, Mar 2, 2010 at 1:04 PM, Ross Boylan wrote:
>>> > On Tue, 2010-03-02 at 05:34 -0600, Pat Kane wrote:
>>> >> On Mon, Mar 1, 2010 at 2:35 PM, Ross Boylan
>>> >> wrote:
>>> >> > Do I need to create a complete xorg.conf?
>>> >>
>>> >>
>>> >> The command "Xorg -configure" will create one for you.
>>> > Hooray! With some hacking I got it working. However, I want to report
>>> > that Xorg -configure generated a segfault, and I'd like to improve my
>>> > understanding of how configuration works.
>>
>>
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: vesa driver reports many modes, but only allows a few
Ross Boylan wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) where
> #0 0x in ?? ()
> #1 0x0051a72a in DoConfigure ()
> at ../../../../hw/xfree86/common/xf86Configure.c:832
The traceback says that someone branched to zero at
line 832 of hw/xfree86/common/xf86Configure.c, that
section of code (from git master) looks like this:
ConfiguredMonitor = NULL;
xf86EnableAccess(xf86Screens[dev2screen[j]]);
if ((*xf86Screens[dev2screen[j]]->PreInit)(xf86Screens[dev2screen[j]],
832: PROBE_DETECT) &&
ConfiguredMonitor) {
MonitorPtr = configureDDCMonitorSection(j);
} else {
MonitorPtr = configureMonitorSection(j);
}
So it appears that the expression:
(*xf86Screens[dev2screen[j]]->PreInit)
is NULL; it would be a good idea for that code to check
if PreInit has been filled in before jumping through it.
Can you recompile the X server with a test for NULL?
Pat
---
On Wed, Mar 3, 2010 at 6:12 PM, Ross Boylan wrote:
> On Wed, 2010-03-03 at 15:41 -0600, Pat Kane wrote:
>> Could you run the configure under gdb to see if you get a better trace back?
>>
>> $gdb Xorg
>> :r -configure
>>
>> could be some xemu hw emulated hw weirdness...
>>
> I also loaded some debug symbols.
>
> [tcsetpgrp failed in terminal_inferior: Operation not permitted]
> (++) Using config file: "/root/xorg.conf.new"
> (EE) open /dev/fb0: No such file or directory
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) where
> #0 0x in ?? ()
> #1 0x0051a72a in DoConfigure ()
> at ../../../../hw/xfree86/common/xf86Configure.c:832
> #2 0x00471c17 in InitOutput (pScreenInfo=0x7d5a80, argc= optimized out>, argv=)
> at ../../../../hw/xfree86/common/xf86Init.c:610
> #3 0x00425a25 in main (argc=2, argv=0x7fffe258, envp= optimized out>) at ../../dix/main.c:203
>
> Ross
>
>>
>> On Tue, Mar 2, 2010 at 1:04 PM, Ross Boylan wrote:
>> > On Tue, 2010-03-02 at 05:34 -0600, Pat Kane wrote:
>> >> On Mon, Mar 1, 2010 at 2:35 PM, Ross Boylan wrote:
>> >> > Do I need to create a complete xorg.conf?
>> >>
>> >>
>> >> The command "Xorg -configure" will create one for you.
>> > Hooray! With some hacking I got it working. However, I want to report
>> > that Xorg -configure generated a segfault, and I'd like to improve my
>> > understanding of how configuration works.
>
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: vesa driver reports many modes, but only allows a few
On Wed, 2010-03-03 at 15:41 -0600, Pat Kane wrote: > Could you run the configure under gdb to see if you get a better trace back? > > $gdb Xorg > :r -configure > > could be some xemu hw emulated hw weirdness... > I also loaded some debug symbols. [tcsetpgrp failed in terminal_inferior: Operation not permitted] (++) Using config file: "/root/xorg.conf.new" (EE) open /dev/fb0: No such file or directory Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) where #0 0x in ?? () #1 0x0051a72a in DoConfigure () at ../../../../hw/xfree86/common/xf86Configure.c:832 #2 0x00471c17 in InitOutput (pScreenInfo=0x7d5a80, argc=, argv=) at ../../../../hw/xfree86/common/xf86Init.c:610 #3 0x00425a25 in main (argc=2, argv=0x7fffe258, envp=) at ../../dix/main.c:203 Ross > > On Tue, Mar 2, 2010 at 1:04 PM, Ross Boylan wrote: > > On Tue, 2010-03-02 at 05:34 -0600, Pat Kane wrote: > >> On Mon, Mar 1, 2010 at 2:35 PM, Ross Boylan wrote: > >> > Do I need to create a complete xorg.conf? > >> > >> > >> The command "Xorg -configure" will create one for you. > > Hooray! With some hacking I got it working. However, I want to report > > that Xorg -configure generated a segfault, and I'd like to improve my > > understanding of how configuration works. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: vesa driver reports many modes, but only allows a few
On Tue, 2010-03-02 at 05:34 -0600, Pat Kane wrote: > On Mon, Mar 1, 2010 at 2:35 PM, Ross Boylan wrote: > > Do I need to create a complete xorg.conf? > > > The command "Xorg -configure" will create one for you. Hooray! With some hacking I got it working. However, I want to report that Xorg -configure generated a segfault, and I'd like to improve my understanding of how configuration works. First, I still don't understand how the defaults work. I thought xorg was supposed to figure out default values for omitted sections. Is it really all or nothing, that is, no xorg.conf or one with all sections? Second, Xorg -configure gave me a segfault. Here's the terminal log: X.Org X Server 1.7.5 Release Date: 2010-02-16 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32.8-dsa-amd64 x86_64 Debian Current Operating System: Linux squeeze00 2.6.32-trunk-amd64 #1 SMP Sun Jan 10 22:40:40 UTC 2010 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-trunk-amd64 root=UUID=5214601b-a9c6-496a-95cf-99962f6bb215 ro quiet Build Date: 16 February 2010 10:23:38AM xorg-server 2:1.7.5-1 (bui...@brahms.debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Mar 2 10:06:16 2010 List of video drivers: mga siliconmotion sis chips s3 savage trident voodoo ark apm neomagic nv vmware v4l rendition intel ati s3virge sisusb i128 openchrome radeonhd mach64 r128 cirrus tdfx radeon tseng fbdev vesa (++) Using config file: "/root/xorg.conf.new" (EE) open /dev/fb0: No such file or directory Backtrace: 0: Xorg (xorg_backtrace+0x28) [0x4a0b88] 1: Xorg (0x40+0x64259) [0x464259] 2: /lib/libpthread.so.0 (0x7f8e67356000+0xe990) [0x7f8e67364990] Segmentation fault at address (nil) Fatal server error: Caught signal 11 (Segmentation fault). Server aborting Third, this did create an xorg.conf.new, but the only device section was fbdev, not vesa. It's unclear to me if any of the input device sections had any effect, and the log shows a lot of failed attempts to set up input devices. Is that normal? My expectation is that Xorg -config figures out where things are and only puts in appropriate sections. Maybe that's not possible because the naming of devices is unpredictable across reboots? For example, the generated file had Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection But I see no reference to /dev/input/mice in Xorg.0.log. /dev/input/mouse[012] are tried; all appear to fail with (II) config/udev: Adding input device "ImExPS/2 Generic Explorer Mouse" (/dev/input/mouse2) (**) "ImExPS/2 Generic Explorer Mouse": always reports core events (**) "ImExPS/2 Generic Explorer Mouse": Device: "/dev/input/mouse2" (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device (II) UnloadModule: "evdev" Thanks to Pat and Adam for their help. Ross Boylan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: vesa driver reports many modes, but only allows a few
On Mon, Mar 1, 2010 at 2:35 PM, Ross Boylan wrote: > Do I need to create a complete xorg.conf? The command "Xorg -configure" will create one for you. Pat --- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: vesa driver reports many modes, but only allows a few
On Mon, 2010-03-01 at 14:40 -0500, Adam Jackson wrote: > On Sun, 2010-02-28 at 23:28 -0800, Ross Boylan wrote: > > Could anyone explain to me what the attached log means? > > > > X 7.5 detects a rich array of BIOS modes, but then runs through a list > > of modes and says "no mode of this name". Should it be using something > > like "104" or "104 (1024x768)" instead of, e.g., "1024x768"? Then X > > tries a less strict probe, and rejects all but a couple of > > low-resolution modes with "hsync out of range". I have no xorg.conf > > file. > > The vesa driver attempts to find the intersection of the list of modes > in the BIOS with the list of modes from EDID. You don't have an EDID, > so this (unsurprisingly) gives you no modes. > > If we get to this point, we attempt to validate the BIOS mode list > against the sync ranges configured for the monitor in xorg.conf, or from > the defaults if there's no explicit configuration. That's what the > "trying less strict filter" bit means. The default sync ranges for your > server appear to be just big enough for 800x600. > > If you want bigger modes, configure a bigger sync range: > > # big enough for 1600x1200 @ 60Hz > Section "Monitor" > Identifier "Monitor0" > HorizSync 31.5 - 75.0 > VertRefresh 56.0 - 61.0 > EndSection I tried an xorg.conf that had *only* the previous Monitor section. It didn't seem to get hooked up to anything else. I also tried giving it an identifier of "" since the log indicated that was the monitor being used. In either case, I got (==) Using config file: "/etc/X11/xorg.conf" (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |-->Screen "Default Screen Section" (0) (**) | |-->Monitor "" (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. Do I need to create a complete xorg.conf? Ross > > Use the gtf(1) utility to calculate the upper bounds for sync ranges for > the resolution you want: > > % gtf 1600 1200 60 > > # 1600x1200 @ 60.00 Hz (GTF) hsync: 74.52 kHz; pclk: 160.96 MHz > Modeline "1600x1200_60.00" 160.96 1600 1704 1880 2160 1200 1201 1204 > 1242 -HSync +Vsync > > - ajax > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: vesa driver reports many modes, but only allows a few
On Sun, 2010-02-28 at 23:28 -0800, Ross Boylan wrote: > Could anyone explain to me what the attached log means? > > X 7.5 detects a rich array of BIOS modes, but then runs through a list > of modes and says "no mode of this name". Should it be using something > like "104" or "104 (1024x768)" instead of, e.g., "1024x768"? Then X > tries a less strict probe, and rejects all but a couple of > low-resolution modes with "hsync out of range". I have no xorg.conf > file. The vesa driver attempts to find the intersection of the list of modes in the BIOS with the list of modes from EDID. You don't have an EDID, so this (unsurprisingly) gives you no modes. If we get to this point, we attempt to validate the BIOS mode list against the sync ranges configured for the monitor in xorg.conf, or from the defaults if there's no explicit configuration. That's what the "trying less strict filter" bit means. The default sync ranges for your server appear to be just big enough for 800x600. If you want bigger modes, configure a bigger sync range: # big enough for 1600x1200 @ 60Hz Section "Monitor" Identifier "Monitor0" HorizSync 31.5 - 75.0 VertRefresh 56.0 - 61.0 EndSection Use the gtf(1) utility to calculate the upper bounds for sync ranges for the resolution you want: % gtf 1600 1200 60 # 1600x1200 @ 60.00 Hz (GTF) hsync: 74.52 kHz; pclk: 160.96 MHz Modeline "1600x1200_60.00" 160.96 1600 1704 1880 2160 1200 1201 1204 1242 -HSync +Vsync - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: vesa driver reports many modes, but only allows a few
To get higherVMware X display resolutions I had to add these to the xorg.conf file inside my virtual machine: Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" HorizSync10 - 300 VertRefresh 10 - 200 EndSection SubSection "Display" Viewport 0 0 Depth 24 Modes "1024x768" EndSubSection Does that help? Pat --- On Mon, Mar 1, 2010 at 1:28 AM, Ross Boylan wrote: > Could anyone explain to me what the attached log means? > > X 7.5 detects a rich array of BIOS modes, but then runs through a list > of modes and says "no mode of this name". Should it be using something > like "104" or "104 (1024x768)" instead of, e.g., "1024x768"? Then X > tries a less strict probe, and rejects all but a couple of > low-resolution modes with "hsync out of range". I have no xorg.conf > file. > > X is running inside a VM, to which I'm connected via vnc. The VM is > running Debian squeeze (testing). When it starts up, the boot screen > appears to be 640x480. If I launch an X session, I get 800x600. I > would like higher resolutions in both terminal and X mode. > > The host runs qemu-kvm-0.12.2, compiled from source on Debian lenny > (stable), amd64 architecture (Xeon). The VM is also amd64, with > multiple CPU's. > > I don't need to do anything special to get the tablet device recognized, > which is nice improvement over X 7.3 on Debian Lenny. But something is > going wrong with the video. Other bugs on the net suggest that the > virtual display adapter is not advertising its modes properly. > Consistent with that, the DDC does not seem to work; there is a message > "VESA VBE DDC not supported". However, the log lists many video modes; > it appears X is getting the information it needs. > > I have tried various xorg.conf's, but have gotten nowhere--apparently if I > define one section I need to define all the others. The logs don't seem > to have any modelines, ruling out the simple solution given in the FAQ. > > I launch with > sudo vdeq bin/qemu-system-x86_64 -net > nic,vlan=1,macaddr=52:54:a0:16:01:01 \ > -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ > -boot c \ > -vga std -vnc localhost:7 -usbdevice tablet \ > -name Squeeze00 \ > -hda /dev/turtle/Squeeze00 \ > -soundhw es1370 -m 1G -smp 4 > > Of course, I'd also welcome help with the virtual machine, but I only > came to this list for help on the X part. Why are video modes being > detected but not used? Is there an xorg.conf I can specify that will > work around the problem? > > Thanks. > Ross Boylan > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
vesa driver reports many modes, but only allows a few
Could anyone explain to me what the attached log means? X 7.5 detects a rich array of BIOS modes, but then runs through a list of modes and says "no mode of this name". Should it be using something like "104" or "104 (1024x768)" instead of, e.g., "1024x768"? Then X tries a less strict probe, and rejects all but a couple of low-resolution modes with "hsync out of range". I have no xorg.conf file. X is running inside a VM, to which I'm connected via vnc. The VM is running Debian squeeze (testing). When it starts up, the boot screen appears to be 640x480. If I launch an X session, I get 800x600. I would like higher resolutions in both terminal and X mode. The host runs qemu-kvm-0.12.2, compiled from source on Debian lenny (stable), amd64 architecture (Xeon). The VM is also amd64, with multiple CPU's. I don't need to do anything special to get the tablet device recognized, which is nice improvement over X 7.3 on Debian Lenny. But something is going wrong with the video. Other bugs on the net suggest that the virtual display adapter is not advertising its modes properly. Consistent with that, the DDC does not seem to work; there is a message "VESA VBE DDC not supported". However, the log lists many video modes; it appears X is getting the information it needs. I have tried various xorg.conf's, but have gotten nowhere--apparently if I define one section I need to define all the others. The logs don't seem to have any modelines, ruling out the simple solution given in the FAQ. I launch with sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:16:01:01 \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ -boot c \ -vga std -vnc localhost:7 -usbdevice tablet \ -name Squeeze00 \ -hda /dev/turtle/Squeeze00 \ -soundhw es1370 -m 1G -smp 4 Of course, I'd also welcome help with the virtual machine, but I only came to this list for help on the X part. Why are video modes being detected but not used? Is there an xorg.conf I can specify that will work around the problem? Thanks. Ross Boylan Xorg.0.log.bz2 Description: application/bzip ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
