How to add a resolution when using vesa driver
Hello, I ran into an issue trying to use the vesa driver on my slackware laptop when I try to add a resolution greater than 1024 x 768. My previous call for help located here : https://www.linuxquestions.org/questions/slackware-14/adding-a-resolution-when-using-xorg-vesa-conf-4175673896/ [http://images.linuxquestions.org/lqthumb.png]<https://www.linuxquestions.org/questions/slackware-14/adding-a-resolution-when-using-xorg-vesa-conf-4175673896/> Adding a resolution when using xorg-vesa.conf<https://www.linuxquestions.org/questions/slackware-14/adding-a-resolution-when-using-xorg-vesa-conf-4175673896/> Welcome to LinuxQuestions.org, a friendly and active Linux Community. You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. www.linuxquestions.org led me to this list. Please see the link to look at what has already been tested. Any help will be appreciated. Thanks, A ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: VESA Driver does not see 1920x1200_60.00 of HP LP2465 on RV370 Radeon
On 21/01/2020 12:38, Michel Dänzer wrote:
On 2020-01-21 12:31 a.m., Danie Wessels wrote:
On 20/01/2020 15:39, Michel Dänzer wrote:
On 2020-01-20 6:37 a.m., Danie Wessels wrote:
On 17/01/2020 13:16, Michel Dänzer wrote:
On 2020-01-16 10:49 p.m., Danie Wessels wrote:
Hi
I have just upgraded Centos 7 to 8 on this same hardware and previous
gnome installation was fine with 1920x1200 resolution on the HP LP2465
(24" ) monitor. (BTW: Upgrade did not go smooth due to insufficient
space on root partition).
The problem is that the maximum resolution available for selection is
now only 1280x1024. Not sure if fglrx driver should now be used
instead
of VESA. I don't know the next step to get the auto detect to correct
this.
The next step is to check dmesg for why the radeon kernel driver didn't
initialize HW acceleration.
Thank you for your response.
I had look but, don't see anything. See attached file a.
There's no trace of the radeon kernel driver even getting loaded. Does
running
sudo modprobe radeon
manually work? If yes, maybe it's blacklisted e.g. in a file under
/etc/modprobe.d/. If no, provide the output from modprobe and from dmesg
after trying it.
sudo modprobe radeon
[sudo] password for danie:
modprobe: FATAL: Module radeon not found in directory
/lib/modules/4.18.0-147.3.1.el8_1.x86_64
Looks like it's missing. Is the kernel-modules-4.18.0-147.3.1.el8_1
package installed?
Thank you! I installed that and had to reboot after modprobe (ofcourse 8^().
That problem is now resolved. I get 1920 x 1200 (16:10) (for Hewlett
Packard 24" Display) Yeah!
but , I don't understand the following (NOT important though)
modprobe radeon
modprobe: FATAL: Module radeon not found in directory
/lib/modules/3.10.0-862.el7.x86_64
# grep radeon /var/log/Xorg.0.log
{nothing}
# grep radeon /var/log/messages
Jan 20 15:45:56 donderweer-wessels dbus-daemon[951]: [system] Activating
via systemd: service name='net.reactivated.Fprint'
unit='fprintd.service' requested by ':1.749' (uid=0 pid=21245 comm="sudo
modprobe radeon ")
Jan 20 16:02:20 donderweer-wessels dbus-daemon[951]: [system] Activating
via systemd: service name='net.reactivated.Fprint'
unit='fprintd.service' requested by ':1.771' (uid=0 pid=22008 comm="sudo
modprobe radeon ")
Jan 20 19:50:09 donderweer-wessels kernel: [drm] radeon kernel
modesetting enabled.
Jan 20 19:50:09 donderweer-wessels kernel: radeon :01:00.0: VRAM:
256M 0xD000 - 0xDFFF (256M used)
Jan 20 19:50:09 donderweer-wessels kernel: radeon :01:00.0: GTT:
512M 0xB000 - 0xCFFF
Jan 20 19:50:09 donderweer-wessels kernel: [drm] radeon: 256M of VRAM
memory ready
Jan 20 19:50:09 donderweer-wessels kernel: [drm] radeon: 512M of GTT
memory ready.
Jan 20 19:50:09 donderweer-wessels kernel: [drm] radeon: 1 quad pipes, 1
Z pipes initialized
Jan 20 19:50:09 donderweer-wessels kernel: radeon :01:00.0: WB enabled
Jan 20 19:50:09 donderweer-wessels kernel: radeon :01:00.0: fence
driver on ring 0 use gpu addr 0xb000 and cpu addr
0x8d1272f19000
Jan 20 19:50:09 donderweer-wessels kernel: radeon :01:00.0: radeon:
MSI limited to 32-bit
Jan 20 19:50:09 donderweer-wessels kernel: radeon :01:00.0: radeon:
using MSI.
Jan 20 19:50:09 donderweer-wessels kernel: [drm] radeon: irq initialized.
Jan 20 19:50:09 donderweer-wessels kernel: [drm] radeon: ring at
0xB0001000
Jan 20 19:50:09 donderweer-wessels kernel: fbcon: radeondrmfb (fb0) is
primary device
Jan 20 19:50:10 donderweer-wessels kernel: radeon :01:00.0: fb0:
radeondrmfb frame buffer device
Jan 20 19:50:10 donderweer-wessels kernel: [drm] Initialized radeon
2.50.0 20080528 for :01:00.0 on minor 0
Jan 21 01:39:19 donderweer-wessels /usr/libexec/gdm-x-session[16924]:
(II) LoadModule: "radeon"
Jan 21 01:39:19 donderweer-wessels /usr/libexec/gdm-x-session[16924]:
(II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so
Jan 21 01:39:19 donderweer-wessels /usr/libexec/gdm-x-session[16924]:
(II) Module radeon: vendor="X.Org Foundation"
Jan 21 01:39:19 donderweer-wessels /usr/libexec/gdm-x-session[16924]:
(II) UnloadModule: "radeon"
Jan 21 13:37:53 donderweer-wessels kernel: [drm] radeon kernel
modesetting enabled.
Jan 21 13:37:53 donderweer-wessels kernel: radeon :01:00.0: vgaarb:
deactivate vga console
Jan 21 13:37:53 donderweer-wessels kernel: radeon :01:00.0: VRAM:
256M 0xD000 - 0xDFFF (256M used)
Jan 21 13:37:53 donderweer-wessels kernel: radeon :01:00.0: GTT:
512M 0xB000 - 0xCFFF
Jan 21 13:37:53 donderweer-wessels kernel: [drm] radeon: 256M of VRAM
memory ready
Jan 21 13:37:53 donderweer-wessels kernel: [drm] radeon: 512M of GTT
memory ready.
Jan 21 13:37:53 donderweer-wessels kernel: [drm] radeon: 1 quad pipes, 1
Z pipes initialized
Jan 21 13:37:53 donderweer-wessels kernel: radeon :01:00.0: WB enabled
Jan 21 13:37:53 donderweer-wessels kernel:
Re: VESA Driver does not see 1920x1200_60.00 of HP LP2465 on RV370 Radeon
On 2020-01-21 12:31 a.m., Danie Wessels wrote: > On 20/01/2020 15:39, Michel Dänzer wrote: >> On 2020-01-20 6:37 a.m., Danie Wessels wrote: >>> On 17/01/2020 13:16, Michel Dänzer wrote: On 2020-01-16 10:49 p.m., Danie Wessels wrote: > Hi > > I have just upgraded Centos 7 to 8 on this same hardware and previous > gnome installation was fine with 1920x1200 resolution on the HP LP2465 > (24" ) monitor. (BTW: Upgrade did not go smooth due to insufficient > space on root partition). > > The problem is that the maximum resolution available for selection is > now only 1280x1024. Not sure if fglrx driver should now be used > instead > of VESA. I don't know the next step to get the auto detect to correct > this. The next step is to check dmesg for why the radeon kernel driver didn't initialize HW acceleration. >>> Thank you for your response. >>> >>> I had look but, don't see anything. See attached file a. >> >> There's no trace of the radeon kernel driver even getting loaded. Does >> running >> >> sudo modprobe radeon >> >> manually work? If yes, maybe it's blacklisted e.g. in a file under >> /etc/modprobe.d/. If no, provide the output from modprobe and from dmesg >> after trying it. >> >> > sudo modprobe radeon > [sudo] password for danie: > modprobe: FATAL: Module radeon not found in directory > /lib/modules/4.18.0-147.3.1.el8_1.x86_64 Looks like it's missing. Is the kernel-modules-4.18.0-147.3.1.el8_1 package installed? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: VESA Driver does not see 1920x1200_60.00 of HP LP2465 on RV370 Radeon
On 20/01/2020 15:39, Michel Dänzer wrote: On 2020-01-20 6:37 a.m., Danie Wessels wrote: On 17/01/2020 13:16, Michel Dänzer wrote: On 2020-01-16 10:49 p.m., Danie Wessels wrote: Hi I have just upgraded Centos 7 to 8 on this same hardware and previous gnome installation was fine with 1920x1200 resolution on the HP LP2465 (24" ) monitor. (BTW: Upgrade did not go smooth due to insufficient space on root partition). The problem is that the maximum resolution available for selection is now only 1280x1024. Not sure if fglrx driver should now be used instead of VESA. I don't know the next step to get the auto detect to correct this. The next step is to check dmesg for why the radeon kernel driver didn't initialize HW acceleration. Thank you for your response. I had look but, don't see anything. See attached file a. There's no trace of the radeon kernel driver even getting loaded. Does running sudo modprobe radeon manually work? If yes, maybe it's blacklisted e.g. in a file under /etc/modprobe.d/. If no, provide the output from modprobe and from dmesg after trying it. sudo modprobe radeon [sudo] password for danie: modprobe: FATAL: Module radeon not found in directory /lib/modules/4.18.0-147.3.1.el8_1.x86_64 -=- Then I did rpm -qa | grep x11-drv xorg-x11-drv-evdev-2.10.6-2.el8.x86_64 xorg-x11-drv-vesa-2.4.0-3.el8.x86_64 xorg-x11-drv-wacom-serial-support-0.36.1-5.el8.x86_64 xorg-x11-drv-fbdev-0.5.0-2.el8.x86_64 xorg-x11-drv-vmware-13.2.1-8.el8.x86_64 xorg-x11-drv-nouveau-1.0.15-4.el8.1.x86_64 xorg-x11-drv-intel-2.99.917-38.20180618.el8.x86_64 xorg-x11-drv-void-1.4.1-2.el7.1.x86_64 xorg-x11-drv-wacom-0.36.1-5.el8.x86_64 xorg-x11-drv-libinput-0.28.0-2.el8.x86_64 xorg-x11-drv-v4l-0.3.0-2.el8.x86_64 xorg-x11-drv-qxl-0.1.5-9.el8.x86_64 xorg-x11-drv-ati-19.0.1-1.el8.x86_64 xorg-x11-drv-dummy-0.3.7-6.el8.1.x86_64 So, the old el7 driver still there - good and bad since could be the source of my problem. -=-= dnf remove xorg-x11-drv-ati-19.0.1-2.el7.x86_64 Dependencies resolved. Package Architecture Version Repository Size Removing: xorg-x11-drv-ati x86_64 19.0.1-2.el7 @System 524 k Removing dependent packages: xorg-x11-drivers x86_64 7.7-22.el8 @AppStream0 : -=-= The I did dnf install xorg-x11-drivers-7.7-22.el8 --best --allowerasing Last metadata expiration check: 0:04:27 ago on Mon 20 Jan 2020 15:57:01 SAST. Dependencies resolved. Package Architecture Version Repository Size Installing: xorg-x11-drivers x86_64 7.7-22.el8 AppStream 16 k Installing dependencies: xorg-x11-drv-ati x86_64 19.0.1-1.el8 AppStream 175 k Transaction Summary Install 2 Packages Total download size: 190 k Installed size: 612 k : -=-= But still: modprobe radeon modprobe: FATAL: Module radeon not found in directory /lib/modules/4.18.0-147.3.1.el8_1.x86_64 Then I removed ALL .el7 rpm installed that still was left - which meant a lot of .el8 rpm uninstallations and reinstallations. -=-= But still: modprobe radeon modprobe: FATAL: Module radeon not found in directory /lib/modules/4.18.0-147.3.1.el8_1.x86_64 -=-= ls /etc/modprobe.d/ firewalld-sysctls.conf lockd.conf nvdimm-security.conf tuned.conf kvm.confmlx4.conf truescale.confvhost.conf Regards -- Danie Wessels ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: VESA Driver does not see 1920x1200_60.00 of HP LP2465 on RV370 Radeon
On 20/01/2020 15:39, Michel Dänzer wrote: On 2020-01-20 6:37 a.m., Danie Wessels wrote: On 17/01/2020 13:16, Michel Dänzer wrote: On 2020-01-16 10:49 p.m., Danie Wessels wrote: Hi I have just upgraded Centos 7 to 8 on this same hardware and previous gnome installation was fine with 1920x1200 resolution on the HP LP2465 (24" ) monitor. (BTW: Upgrade did not go smooth due to insufficient space on root partition). The problem is that the maximum resolution available for selection is now only 1280x1024. Not sure if fglrx driver should now be used instead of VESA. I don't know the next step to get the auto detect to correct this. The next step is to check dmesg for why the radeon kernel driver didn't initialize HW acceleration. Thank you for your response. I had look but, don't see anything. See attached file a. There's no trace of the radeon kernel driver even getting loaded. Does running sudo modprobe radeon manually work? If yes, maybe it's blacklisted e.g. in a file under /etc/modprobe.d/. If no, provide the output from modprobe and from dmesg after trying it. The saga continues... ls -l /lib/modules/4.18.0-147.3.1.el8_1.x86_64 totaal 13420 -rw-r--r-- 1 root root 325 Jan 4 02:02 bls.conf lrwxrwxrwx 1 root root 44 Jan 4 02:02 build -> /usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64 -rw-r--r-- 1 root root 184825 Jan 4 02:02 config drwxr-xr-x 12 root root 128 Jan 15 20:06 kernel -rw-r--r-- 1 root root 207133 Jan 15 20:13 modules.alias -rw-r--r-- 1 root root 209189 Jan 15 20:13 modules.alias.bin -rw-r--r-- 1 root root 488 Jan 4 02:02 modules.block -rw-r--r-- 1 root root7534 Jan 4 02:02 modules.builtin -rw-r--r-- 1 root root9748 Jan 15 20:13 modules.builtin.bin -rw-r--r-- 1 root root 90662 Jan 15 20:13 modules.dep -rw-r--r-- 1 root root 141992 Jan 15 20:13 modules.dep.bin -rw-r--r-- 1 root root 269 Jan 15 20:13 modules.devname -rw-r--r-- 1 root root 140 Jan 4 02:02 modules.drm -rw-r--r-- 1 root root 59 Jan 4 02:02 modules.modesetting -rw-r--r-- 1 root root1595 Jan 4 02:02 modules.networking -rw-r--r-- 1 root root 98346 Jan 4 02:02 modules.order -rw-r--r-- 1 root root 563 Jan 15 20:13 modules.softdep -rw-r--r-- 1 root root 203645 Jan 15 20:13 modules.symbols -rw-r--r-- 1 root root 243404 Jan 15 20:13 modules.symbols.bin lrwxrwxrwx 1 root root 5 Jan 4 02:02 source -> build -rw-r--r-- 1 root root 339854 Jan 4 02:02 symvers.gz -rw--- 1 root root 3841454 Jan 4 02:02 System.map drwxr-xr-x 2 root root 6 Jan 4 02:02 updates drwxr-xr-x 2 root root 40 Jan 15 20:06 vdso -rwxr-xr-x 1 root root 8106744 Jan 4 02:02 vmlinuz drwxr-xr-x 2 root root 6 Jan 4 02:02 weak-updates # less /lib/modules/4.18.0-147.3.1.el8_1.x86_64/modules.alias [root@donderweer-wessels ~]# grep radeon /lib/modules/4.18.0-147.3.1.el8_1.x86_64/modules.* /lib/modules/4.18.0-147.3.1.el8_1.x86_64/modules.drm:radeon.ko /lib/modules/4.18.0-147.3.1.el8_1.x86_64/modules.modesetting:radeon.ko /lib/modules/4.18.0-147.3.1.el8_1.x86_64/modules.order:kernel/drivers/gpu/drm/radeon/radeon.ko # insmod radeon insmod: ERROR: could not load module radeon: No such file or directory [root@donderweer-wessels ~]# ls /lib/modules/4.18.0-147.3.1.el8_1.x86_64/kernel/drivers/gpu/drm/radeon/radeon.ko ls: kan nie toegang verkry na '/lib/modules/4.18.0-147.3.1.el8_1.x86_64/kernel/drivers/gpu/drm/radeon/radeon.ko' nie: No such file or directory # ls /lib/modules/4.18.0-147.3.1.el8_1.x86_64/kernel/drivers/gpu/drm/radeon/ Regards -- Danie Wessels ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: VESA Driver does not see 1920x1200_60.00 of HP LP2465 on RV370 Radeon
On 2020-01-20 6:37 a.m., Danie Wessels wrote: > On 17/01/2020 13:16, Michel Dänzer wrote: >> On 2020-01-16 10:49 p.m., Danie Wessels wrote: >>> Hi >>> >>> I have just upgraded Centos 7 to 8 on this same hardware and previous >>> gnome installation was fine with 1920x1200 resolution on the HP LP2465 >>> (24" ) monitor. (BTW: Upgrade did not go smooth due to insufficient >>> space on root partition). >>> >>> The problem is that the maximum resolution available for selection is >>> now only 1280x1024. Not sure if fglrx driver should now be used instead >>> of VESA. I don't know the next step to get the auto detect to correct >>> this. >> >> The next step is to check dmesg for why the radeon kernel driver didn't >> initialize HW acceleration. >> >> > Thank you for your response. > > I had look but, don't see anything. See attached file a. There's no trace of the radeon kernel driver even getting loaded. Does running sudo modprobe radeon manually work? If yes, maybe it's blacklisted e.g. in a file under /etc/modprobe.d/. If no, provide the output from modprobe and from dmesg after trying it. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: VESA Driver does not see 1920x1200_60.00 of HP LP2465 on RV370 Radeon
On 17/01/2020 13:16, Michel Dänzer wrote: On 2020-01-16 10:49 p.m., Danie Wessels wrote: Hi I have just upgraded Centos 7 to 8 on this same hardware and previous gnome installation was fine with 1920x1200 resolution on the HP LP2465 (24" ) monitor. (BTW: Upgrade did not go smooth due to insufficient space on root partition). The problem is that the maximum resolution available for selection is now only 1280x1024. Not sure if fglrx driver should now be used instead of VESA. I don't know the next step to get the auto detect to correct this. The next step is to check dmesg for why the radeon kernel driver didn't initialize HW acceleration. Thank you for your response. I had look but, don't see anything. See attached file a. Regards -- Danie Wessels [0.00] microcode: microcode updated early to revision 0xba, date = 2010-10-03 [0.00] Linux version 4.18.0-147.3.1.el8_1.x86_64 (mockbu...@kbuilder.bsys.centos.org) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Fri Jan 3 23:55:26 UTC 2020 [0.00] Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-4.18.0-147.3.1.el8_1.x86_64 root=/dev/mapper/centos_donderweer-root ro crashkernel=auto rd.lvm.lv=centos_donderweer/root rd.lvm.lv=centos_donderweer/swap rhgb quiet [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcfb49fff] usable [0.00] BIOS-e820: [mem 0xcfb4a000-0xcfb8cfff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfb8d000-0xcfce0fff] reserved [0.00] BIOS-e820: [mem 0xcfce1000-0xcfce6fff] ACPI data [0.00] BIOS-e820: [mem 0xcfce7000-0xcfce7fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfce8000-0xcfce9fff] ACPI data [0.00] BIOS-e820: [mem 0xcfcea000-0xcfcebfff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfcec000-0xcfcecfff] reserved [0.00] BIOS-e820: [mem 0xcfced000-0xcfcf0fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfcf1000-0xcfcf] reserved [0.00] BIOS-e820: [mem 0xcfd0-0xcfef] usable [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xffa0-0xffbf] reserved [0.00] BIOS-e820: [mem 0xffe0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00012fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: /DG31PR, BIOS PRG3110H.86A.0052.2008.0612.1910 06/12/2008 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] last_pfn = 0x13 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-D uncachable [0.00] E-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F write-back [0.00] 1 base 1 mask FE000 write-back [0.00] 2 base 12000 mask FF000 write-back [0.00] 3 base 0CFF0 mask 0 uncachable [0.00] 4 base 0D000 mask FF000 uncachable [0.00] 5 base 0E000 mask FE000 uncachable [0.00] 6 disabled [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.00] total RAM covered: 4095M [0.00] Found optimal setting for mtrr clean up [0.00] gran_size: 64K chunk_size: 2M num_reg: 6 lose cover RAM: 0G [0.00] e820: update [mem 0xcff0-0x] usable ==> reserved [0.00] last_pfn = 0xcff00 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fd3c0-0x000fd3cf] mapped at [(ptrval)] [0.00] Base memory trampoline at [(ptrval)] 99000 size 24576 [0.00] BRK [0x9ac01000, 0x9ac01fff] PGTABLE [0.00] BRK [0x9ac02000, 0x9ac02fff] PGTABLE [0.00] BRK [0x9ac03000, 0x9ac03fff] PGTABLE [0.00] BRK [0x9ac04000, 0x9ac04fff] PGTABLE [0.00] BRK [0x9ac05000, 0x9ac05fff] PGTABLE [0.00] BRK [0x9ac06000, 0x9ac06fff] PGTABLE [0.00] BRK [0x9ac07000, 0x9ac07fff] PGTABLE [0.00] RAMDISK: [mem 0x34c9b000-0x36645fff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F03C0 24 (v02 INTEL ) [0.00] ACPI: XSDT 0xCFCE8F10 44 (v01 INTEL
Re: VESA Driver does not see 1920x1200_60.00 of HP LP2465 on RV370 Radeon
On 2020-01-16 10:49 p.m., Danie Wessels wrote: > Hi > > I have just upgraded Centos 7 to 8 on this same hardware and previous > gnome installation was fine with 1920x1200 resolution on the HP LP2465 > (24" ) monitor. (BTW: Upgrade did not go smooth due to insufficient > space on root partition). > > The problem is that the maximum resolution available for selection is > now only 1280x1024. Not sure if fglrx driver should now be used instead > of VESA. I don't know the next step to get the auto detect to correct this. The next step is to check dmesg for why the radeon kernel driver didn't initialize HW acceleration. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
VESA Driver does not see 1920x1200_60.00 of HP LP2465 on RV370 Radeon
M28), ATI Mobility Radeon X800 (M28), ATI Radeon X850, ATI unknown Radeon / FireGL (R480), ATI Radeon X800XT (R423), ATI FireGL V5000 (RV410), ATI Radeon X700 XT (RV410), ATI Radeon X700 PRO (RV410), ATI Radeon X700 SE (RV410), ATI Radeon X700 (RV410), ATI Radeon X1800, ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, ATI Mobility FireGL V7100, ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, ATI Mobility Radeon X1400, ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, ATI Radeon X1300, ATI FireGL V3300, ATI FireGL V3350, ATI Mobility Radeon X1450, ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, ATI FireMV 2250, ATI Radeon X1650, ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, ATI Mobility Radeon X1700 XT, ATI FireGL V5200, ATI Radeon X2300HD, ATI Mobility Radeon HD 2300, ATI Radeon X1950, ATI Radeon X1900, ATI AMD Stream Processor, ATI RV560, ATI Mobility Radeon X1900, ATI Radeon X1950 GT, ATI RV570, ATI FireGL V7400, ATI Radeon 9100 PRO IGP, ATI Radeon Mobility 9200 IGP, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, ATI Radeon HD 4850 x2, ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2, ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98, ATI FirePro M7750, ATI M98, ATI Mobility Radeon HD 4650, ATI Radeon RV730 (AGP), ATI Mobility Radeon HD 4670, ATI FirePro M5750, ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830, ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740, ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI RV610, ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, ATI Mobility Radeon HD 3850, ATI Radeon HD3850, ATI Mobility Radeon HD 3850 X2, ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, ATI Radeon RV710, ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, ATI FirePro RG220, ATI Mobility Radeon 4330, ATI RV630, ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, ATI FireGL V3600, ATI Radeon HD 2600 LE, ATI Mobility FireGL Graphics Processor, ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, ATI Radeon HD 3430, ATI FirePro V3700, ATI FireMV 2450, ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics, ATI Radeon 3000 Graphics, SUMO, SUMO2, ATI Radeon HD 4200, ATI Radeon 4100, ATI Mobility Radeon HD 4200, ATI Mobility Radeon 4100, ATI Radeon HD 4290, ATI Radeon HD 4250, AMD Radeon HD 6310 Graphics, AMD Radeon HD 6250 Graphics, AMD Radeon HD 6300 Series Graphics, AMD Radeon HD 6200 Series Graphics, PALM, CYPRESS, ATI FirePro (FireGL) Graphics Adapter, AMD Firestream 9370, AMD Firestream 9350, ATI Radeon HD 5800 Series, ATI Radeon HD 5900 Series, ATI Mobility Radeon HD 5800 Series, ATI Radeon HD 5700 Series, ATI Radeon HD 6700 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5570, ATI Radeon HD 5670, ATI Radeon HD 5570, ATI Radeon HD 5500 Series, REDWOOD, ATI Mobility Radeon Graphics, CEDAR, ATI FirePro 2270, ATI Radeon HD 5450, CAYMAN, AMD Radeon HD 6900 Series, AMD Radeon HD 6900M Series, Mobility Radeon HD 6000 Series, BARTS, AMD Radeon HD 6800 Series, AMD Radeon HD 6700 Series, TURKS, CAICOS, ARUBA, TAHITI, PITCAIRN, VERDE, OLAND, HAINAN, BONAIRE, KABINI, MULLINS, KAVERI, HAWAII [ 115.956] (II) modesetting: Driver for Mo
vesa driver problem
On Mon, 2018-05-21 at 17:12 +, G. Sebastián Pedersen wrote: /[ 25.201] (II) VESA: driver for VESA chipsets: vesa />>/[ 25.201] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) /> Pretty sure this means your X server isn't running as root, and needs to be. - ajax Probably related to https://bugs.freedesktop.org/show_bug.cgi?id=106588 ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: vesa driver problem
On Mon, 2018-05-21 at 18:35 +, G. Sebastián Pedersen wrote: > May 21, 2018 6:31 PM, "Adam Jackson" <a...@nwnk.net> wrote: > > > On Mon, 2018-05-21 at 17:12 +, G. Sebastián Pedersen wrote: > > > > > [ 25.201] (II) VESA: driver for VESA chipsets: vesa > > > [ 25.201] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not > > > permitted) > > > > Pretty sure this means your X server isn't running as root, and needs > > to be. > > I tried running X as root with no luck (although don't remember if > the specific error you point disapper. Could check it when got home. > The rest remains the same, I'm pretty sure about that.) The other possibility I can think of is that your kernel has been locked down hard enough that userspace isn't allowed to access I/O ports. CONFIG_STRICT_DEVMEM might be guilty here. There's not been any changes in either xserver 1.20 or vesa 2.4.0 that should cause this, though. - ajax ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: vesa driver problem
May 21, 2018 6:31 PM, "Adam Jackson" <a...@nwnk.net> wrote: > On Mon, 2018-05-21 at 17:12 +, G. Sebastián Pedersen wrote: > >> [ 25.201] (II) VESA: driver for VESA chipsets: vesa >> [ 25.201] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not >> permitted) > > Pretty sure this means your X server isn't running as root, and needs > to be. I tried running X as root with no luck (although don't remember if the specific error you point disapper. Could check it when got home. The rest remains the same, I'm pretty sure about that.) Thanks! > > - ajax > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: https://lists.x.org/mailman/listinfo/xorg > Your subscription address: %(user_address)s G. Sebastián Pedersen ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: vesa driver problem
On Mon, 2018-05-21 at 17:12 +, G. Sebastián Pedersen wrote: > [25.201] (II) VESA: driver for VESA chipsets: vesa > [25.201] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not > permitted) Pretty sure this means your X server isn't running as root, and needs to be. - ajax ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
vesa driver problem
Hi guys, I recently update my Parabola Linux (essentially Arch) and X window stop working. Since a few years I use the vesa driver. Asking in the Parabola irc, someone suggest it may be an upstream "problem" with the xorg-server. Here is my Xorg.0.log Any help would be really appreciatted! X.Org X Server 1.20.0 X Protocol Version 11, Revision 0 [24.948] Build Operating System: Linux Arch Linux [24.948] Current Operating System: Linux parabolaSebas64 4.16.8-gnu-1 #1 SMP PREEMPT Sat May 12 03:07:44 UTC 2018 x86_64 [24.948] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux-libre root=UUID=ce1436e8-11c2-44db-99b3-2f02d168a5f1 rw [24.948] Build Date: 16 May 2018 05:24:07PM [24.948] [24.948] Current version of pixman: 0.34.0 [24.948]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [24.948] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [24.949] (==) Log file: "/home/sebas/.local/share/xorg/Xorg.0.log", Time: Sun May 20 01:18:37 2018 [25.000] (==) Using config directory: "/etc/X11/xorg.conf.d" [25.000] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [25.039] (==) No Layout section. Using the first Screen section. [25.039] (**) |-->Screen "Screen0" (0) [25.039] (**) | |-->Monitor "Monitor0" [25.039] (**) | |-->Device "Device0" [25.039] (==) Automatically adding devices [25.039] (==) Automatically enabling devices [25.039] (==) Automatically adding GPU devices [25.039] (==) Automatically binding GPU devices [25.039] (==) Max clients allowed: 256, resource mask: 0x1f [25.073] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/100dpi". [25.073]Entry deleted from font path. [25.073](Run 'mkfontdir' on "/usr/share/fonts/100dpi"). [25.073] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/75dpi". [25.073]Entry deleted from font path. [25.073](Run 'mkfontdir' on "/usr/share/fonts/75dpi"). [25.073] (==) FontPath set to: /usr/share/fonts/misc, /usr/share/fonts/TTF, /usr/share/fonts/OTF, /usr/share/fonts/Type1 [25.073] (==) ModulePath set to "/usr/lib/xorg/modules" [25.073] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [25.073] (II) Module ABI versions: [25.073]X.Org ANSI C Emulation: 0.4 [25.073]X.Org Video Driver: 24.0 [25.073]X.Org XInput driver : 24.1 [25.073]X.Org Server Extension : 10.0 [25.074] (++) using VT number 1 [25.076] (II) systemd-logind: took control of session /org/freedesktop/login1/session/c1 [25.078] (--) PCI:*(1@0:0:0) 1039:6351:1043:82c9 rev 16, Mem @ 0xd000/268435456, 0xfebe/131072, I/O @ 0xec00/128, BIOS @ 0x/131072 [25.078] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) [25.078] (II) LoadModule: "glx" [25.110] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [25.187] (II) Module glx: vendor="X.Org Foundation" [25.187]compiled for 1.20.0, module version = 1.0.0 [25.187]ABI class: X.Org Server Extension, version 10.0 [25.187] (II) LoadModule: "vesa" [25.188] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so [25.201] (II) Module vesa: vendor="X.Org Foundation" [25.201]compiled for 1.20.0, module version = 2.4.0 [25.201]Module class: X.Org Video Driver [25.201]ABI class: X.Org Video Driver, version 24.0 [25.201] (II) VESA: driver for VESA chipsets: vesa [25.201] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) [25.201] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [25.201] (II) Loading sub module "vbe" [25.201] (II) LoadModule: "vbe" [25.202] (II) Loading /usr/lib/xorg/modules/libvbe.so [25.210] (II) Module vbe: vendor="X.Org Foundation" [25.210]compiled for 1.20.0, module version = 1.1.0 [25.210]ABI class: X.Org Video Driver, version 24.0 [25.210] (II) Loading sub module "int10" [25.211] (II) LoadModule: "int10" [25.211] (II) Loading /usr/lib/xorg/modules/libint10.so [25.217] (II) Module int10: vendor="X.Org Foundation" [25.217]compiled for 1.20.0, module version = 1.0.0 [25.217]ABI class: X.Org Video Driver, version 24.0 [25.217] (II) VESA(0): initializing int10 [25.217] (EE) VESA(0): Cannot read int vect [25.217] (II)
VESA driver hack to support modes larger than the startup mode
The goal:
Use the VESA driver and start at a resolution of 1024x768 with a
higher resolution being available using 'xrandr -s 1280x1024'.
This matches what the VMware driver is able to do.
Why we want this:
Our data center uses a switch that allows one physical monitor to
be used with many rack mounted computers.
The KVM switch (Keyboard Video Mouse switch) uses dongles to send
the video signal over Cat5 cabling. The dongles are connected in
series and relay switches in each dongle are used to address a
particular machine.
Video bandwidth varies depending on the length of the cable (as
controlled by the relays) and the solution does not support
DDC/EDID.
The VESA driver is preferred by us as it works with all machines and
having the best video performance is not too important to us.
The smaller resolution of 1024x768 is the best startup default as it
works for machines that have the lowest video bandwidth. This
resolution must be manually configured in xorg.conf because a system
with no xorg.conf will use the highest resolution it finds in the
VESA BIOS (which for some hardware is much too large).
We want to be able to 'xrandr -s 1280x1024' (and back to 1024x768)
just to see if the higher resolution is OK (some machines have
sufficient video bandwidth for this mode). This quick test would be
better that having to quit X and edit xorg.conf by hand.
Some machines boot from the network (PXE) and have no permanent
storage, so we can not edit xorg.conf one time and leave it that
way.
The hoped for solution:
From our xorg.conf:
Modes 1024x768 1280x1024
We had hoped that just adding a second mode would do the trick.
Alas, the virtual display is calculated to accommodate the larger
resolution and the machine starts in 1024x768 but it's a viewport
into a virtual display of 1280x1024. This is the documented
behavior, but it'd not what we want. Adding this:
Virtual 1024 768
Fixes the viewport problem, but the larger mode becomes
unavailable (xrandr does not list it). Also, xrandr can not be used
to add it later as it errors with:
screen cannot be larger than 1024x768
The attempted hack:
We noticed that another driver behaved differently. The VMware
driver (in a virtual machine, forget about our KVM switch for now)
will start at 1024x768 when configured in xorg.conf, but xrandr will
list lots of larger modes (that we did not specify) and xrandr can
be used to switch to them.
Upon inspection of the VMware driver's source code, near the end of
VMWAREScreenInit() (what ScreenInit() points to), we see in
vmware.c:
/*
* We explicitly add a set of default modes because the X server will
* not include modes larger than the initial one.
*/
{
unsigned int i;
unsigned int numModes = sizeof (VMWAREDefaultModes) / sizeof
*(VMWAREDefaultModes);
char name[10];
for (i = 0; i numModes; i++) {
const VMWAREDefaultMode *mode = VMWAREDefaultModes[i];
/* Only modes that fit the hardware maximums should be added. */
if (mode-width = pVMWARE-maxWidth mode-height =
pVMWARE-maxHeight) {
snprintf(name, 10, %dx%d, mode-width, mode-height);
VMWAREAddDisplayMode(pScrn, name, mode-width, mode-height);
}
}
}
Since the VMware driver exhibits our desired behaviour (start at a
lower rez and allow xrandr switching to a higher rez without virtual
display viewport wierdness), we tried to hack that same idea into
the VESA driver.
Our hack (please see attached), successfully allows xrandr switching
to the higher rez and the monitor's info panel confirms that the rez
and timing are correct.
The problem seems to be that the virtual display size is not being
updated to match the higher resolution and appears to be stuck at
the lower rez. This results in an unhappy X display that looks like
there is corrupt video memory in the areas outside the original
resolution.
Assistance required:
We are not skilled X hackers and it's nice that we've even been able
to get this far without really knowing what we're doing... :^)
We are hoping that there is a way to get the virtual display size to
update with the video mode change (a la the VMware driver).
It would be great if someone could please explain how this might be
done. It's not clear to us why this is working for the VMware
driver...
Also, if we can get this working in the VESA driver, would this be
acceptable (if given some polish vs. using one hard-coded mode) as a
patch? If the current behaviour is deemed to be desirable, maybe we
could create a new VESA driver specific option that would cause the
driver to add higher modes if specified?
We like that X can run without a conf file these days, but if a conf
file is being used, it would be nice to have the flexibility to
start at a lower
xorg 1.17.1 stopped working for VESA driver
As I have been told by MrElendig, there is probably an upstream bug in 1.17.1 version of xorg when dealing with VESA driver. After upgrading to 1.17.1 I also have confirmed that XFCE works remotely in X2GO but it's not working locally. I suppose that's because X2GO doesn't use the video driver. If I roll back to xorg 1.16.4, then XFCE works fine again locally. After upgrading to 1.17.1 it's not possible to start any desktop environment because of the following xorg error: (EE) VESA(0): Cannot read int vect Here is the log: [ 755.573] X.Org X Server 1.17.1 Release Date: 2015-02-10 [ 755.606] X Protocol Version 11, Revision 0 [ 755.618] Build Operating System: Linux 3.18.6-1-ARCH i686 [ 755.631] Current Operating System: Linux Kevin 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:59:29 CET 2015 i686 [ 755.631] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=18a28355-049f-4051-910a-6163cfa9790d rw quiet [ 755.659] Build Date: 22 February 2015 12:52:47PM [ 755.673] [ 755.688] Current version of pixman: 0.32.6 [ 755.719]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 755.719] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 755.787] (==) Log file: /var/log/Xorg.2.log, Time: Mon Feb 23 15:35:08 2015 [ 755.806] (==) Using config file: /etc/X11/xorg.conf [ 755.825] (==) Using system config directory /usr/share/X11/xorg.conf.d [ 755.826] (==) ServerLayout X.org Configured [ 755.826] (**) |--Screen Screen0 (0) [ 755.826] (**) | |--Monitor Monitor0 [ 755.826] (**) | |--Device Card0 [ 755.826] (**) |--Input Device Mouse0 [ 755.826] (**) |--Input Device Keyboard0 [ 755.826] (==) Automatically adding devices [ 755.827] (==) Automatically enabling devices [ 755.827] (==) Automatically adding GPU devices [ 755.827] (WW) `fonts.dir' not found (or not valid) in /usr/share/fonts/TTF/. [ 755.827]Entry deleted from font path. [ 755.827](Run 'mkfontdir' on /usr/share/fonts/TTF/). [ 755.827] (WW) `fonts.dir' not found (or not valid) in /usr/share/fonts/OTF/. [ 755.827]Entry deleted from font path. [ 755.827](Run 'mkfontdir' on /usr/share/fonts/OTF/). [ 755.827] (WW) The directory /usr/share/fonts/Type1/ does not exist. [ 755.827]Entry deleted from font path. [ 755.827] (WW) `fonts.dir' not found (or not valid) in /usr/share/fonts/TTF/. [ 755.827]Entry deleted from font path. [ 755.827](Run 'mkfontdir' on /usr/share/fonts/TTF/). [ 755.827] (WW) `fonts.dir' not found (or not valid) in /usr/share/fonts/OTF/. [ 755.827]Entry deleted from font path. [ 755.827](Run 'mkfontdir' on /usr/share/fonts/OTF/). [ 755.827] (WW) The directory /usr/share/fonts/Type1/ does not exist. [ 755.827]Entry deleted from font path. [ 755.827] (**) FontPath set to: /usr/share/fonts/misc/, /usr/share/fonts/100dpi/, /usr/share/fonts/75dpi/, /usr/share/fonts/misc/, /usr/share/fonts/100dpi/, /usr/share/fonts/75dpi/ [ 755.827] (**) ModulePath set to /usr/lib/xorg/modules [ 755.827] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 755.827] (WW) Disabling Mouse0 [ 755.827] (WW) Disabling Keyboard0 [ 755.827] (II) Loader magic: 0x829e700 [ 755.827] (II) Module ABI versions: [ 755.827]X.Org ANSI C Emulation: 0.4 [ 755.827]X.Org Video Driver: 19.0 [ 755.827]X.Org XInput driver : 21.0 [ 755.827]X.Org Server Extension : 9.0 [ 755.834] (II) systemd-logind: took control of session /org/freedesktop/login1/session/c1 [ 755.837] (--) PCI:*(0:1:0:0) 1106:3344:1849:3344 rev 1, Mem @ 0xf000/67108864, 0xfd00/16777216, BIOS @ 0x/65536 [ 755.837] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) [ 755.837] (II) glx will be loaded. This was enabled by default and also specified in the config file. [ 755.837] (II) LoadModule: glx [ 755.838] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 755.844] (II) Module glx: vendor=X.Org Foundation [ 755.844]compiled for 1.17.1, module version = 1.0.0 [ 755.844]ABI class: X.Org Server Extension, version 9.0 [ 755.844] (==) AIGLX enabled [ 755.844] (II) LoadModule: vesa [ 755.844] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so [ 755.845] (II) Module vesa: vendor=X.Org Foundation [ 755.845]compiled for 1.17.0, module version = 2.3.2 [ 755.845]Module class: X.Org Video Driver [ 755.845]ABI class: X.Org Video Driver, version 19.0 [ 755.845] (II) VESA: driver for VESA chipsets: vesa [ 755.845] (++) using VT number 1 [ 755.845] (--) controlling tty is VT number 1, auto-enabling KeepTty [ 755.845] (II) Loading sub module vbe
Re: Am I using the ati or vesa driver?
So, maybe a bad option or a missing dependency when I try to compile
xorg-server-16.0.
You can see here the full output for the configure line:
http://pastebin.com/wYpk5ek4
(In the future, the config.log file would be more useful)
The problem is this:
checking for GBM... no
Looking at xserver's configure.ac, it actually requires GBM from Mesa
10.2 or newer for building glamor. I think this should be made clearer
in the configure output.
If you can't use Mesa 10.2, you'll have to use the standalone glamor
tree for now.
Thank you.
Upgrading from mesa-9.1.7 (official package in Slackware 14.1) to mesa-10.0.2
was not enough.
So, I have upgraded to mesa-10.2.5.
And very important: the --enable-gbm option!
Here is my configure line:
$ ./configure --prefix=/usr --with-egl-platforms=x11,drm
--with-gallium-drivers=radeonsi --enable-gbm --enable-shared-glapi
--enable-glx-tls --sysconfdir=/etc --libdir=/usr/lib --mandir=/usr/man
--docdir=/usr/doc/mesa-${VERSION}
--with-dri-driverdir=/usr/lib/xorg/modules/dri --with-dri-drivers=i915,i965
--disable-llvm-shared-libs
After this, I have compiled xorg-server-1.16.0 and glamor is available now:
$ find /tmp/xorg-server-1.16.0/ -name *glamor*
/tmp/xorg-server-1.16.0/usr/include/xorg/glamor.h
/tmp/xorg-server-1.16.0/usr/lib/xorg/modules/libglamoregl.so
/tmp/xorg-server-1.16.0/usr/lib/xorg/modules/libglamoregl.la
OK, so now I have direct rendering:
$ grep Direct /var/log/Xorg.0.log
[16.450] (II) RADEON(0): Direct rendering enabled
It works :)
Problem solved.
___
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: %(user_address)s
Re: Am I using the ati or vesa driver?
On Sat, 09 Aug 2014 13:13:46 +0900 Michel Dänzer mic...@daenzer.net wrote: On 08.08.2014 20:23, YuGiOhJCJ Mailing-List wrote: The full log is here: http://pastebin.com/a51DRWg6 (II) Loading sub module glamoregl (II) LoadModule: glamoregl (WW) Warning, couldn't open module glamoregl (II) UnloadModule: glamoregl (II) Unloading glamoregl (EE) RADEON: Failed to load module glamoregl (module does not exist, 0) Looks like libglamoregl.so isn't installed, at least not in /usr/lib/xorg/modules. I have not installed glamor from the glamor tree. I want to use glamor from the xorg-server tree. So, I build and install xorg (with the --enable-glamor option), then after this I build and install the xf86-video-ati driver. But what is strange, is that as you can see before, a libglamoregl.so shared library is required when I type startx. Why? I have said that I would like to use the glamor from the xorg-server tree, so I have not a libglamoregl.so installed file. Indeed, the libglamoregl.so file is provided by glamor from the glamor tree only. Are you agree? No, xserver with --enable-glamor also produces libglamoregl.so. It sounds like either something went wrong building xserver with --enable-glamor, or maybe you didn't specify --prefix=/usr for the xserver build, so it was installed to /usr/local/. OK so yeah it is sure that libglamoregl.so is not present after building xorg-server-16.0: $ tar tvf xorg-server-1.16.0-i486-1_ygo.txz | grep glamor -rw-r--r-- root/root 20481 2014-08-07 13:04 usr/include/xorg/glamor.h So, maybe a bad option or a missing dependency when I try to compile xorg-server-16.0. You can see here the full output for the configure line: http://pastebin.com/wYpk5ek4 An interesting line is: configure: DRI3 disabled because dri3proto not found. Do you think DRI3 is required to have 3d acceleration with radeon? ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
The full log is here: http://pastebin.com/a51DRWg6 (II) Loading sub module glamoregl (II) LoadModule: glamoregl (WW) Warning, couldn't open module glamoregl (II) UnloadModule: glamoregl (II) Unloading glamoregl (EE) RADEON: Failed to load module glamoregl (module does not exist, 0) Looks like libglamoregl.so isn't installed, at least not in /usr/lib/xorg/modules. I have not installed glamor from the glamor tree. I want to use glamor from the xorg-server tree. So, I build and install xorg (with the --enable-glamor option), then after this I build and install the xf86-video-ati driver. But what is strange, is that as you can see before, a libglamoregl.so shared library is required when I type startx. Why? I have said that I would like to use the glamor from the xorg-server tree, so I have not a libglamoregl.so installed file. Indeed, the libglamoregl.so file is provided by glamor from the glamor tree only. Are you agree? No, xserver with --enable-glamor also produces libglamoregl.so. It sounds like either something went wrong building xserver with --enable-glamor, or maybe you didn't specify --prefix=/usr for the xserver build, so it was installed to /usr/local/. OK so yeah it is sure that libglamoregl.so is not present after building xorg-server-16.0: $ tar tvf xorg-server-1.16.0-i486-1_ygo.txz | grep glamor -rw-r--r-- root/root 20481 2014-08-07 13:04 usr/include/xorg/glamor.h So, maybe a bad option or a missing dependency when I try to compile xorg-server-16.0. You can see here the full output for the configure line: http://pastebin.com/wYpk5ek4 An interesting line is: configure: DRI3 disabled because dri3proto not found. Do you think DRI3 is required to have 3d acceleration with radeon? No, with dri3proto, same problem: $ find /tmp/xorg-server-1.16.0/ -name *glamor* /tmp/xorg-server-1.16.0/usr/include/xorg/glamor.h Do you see something strange in my full output for the configure line? (previous message) ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
On 09.08.2014 21:53, YuGiOhJCJ Mailing-List wrote: So, maybe a bad option or a missing dependency when I try to compile xorg-server-16.0. You can see here the full output for the configure line: http://pastebin.com/wYpk5ek4 (In the future, the config.log file would be more useful) The problem is this: checking for GBM... no Looking at xserver's configure.ac, it actually requires GBM from Mesa 10.2 or newer for building glamor. I think this should be made clearer in the configure output. If you can't use Mesa 10.2, you'll have to use the standalone glamor tree for now. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
On 08.08.2014 20:23, YuGiOhJCJ Mailing-List wrote: The full log is here: http://pastebin.com/a51DRWg6 (II) Loading sub module glamoregl (II) LoadModule: glamoregl (WW) Warning, couldn't open module glamoregl (II) UnloadModule: glamoregl (II) Unloading glamoregl (EE) RADEON: Failed to load module glamoregl (module does not exist, 0) Looks like libglamoregl.so isn't installed, at least not in /usr/lib/xorg/modules. I have not installed glamor from the glamor tree. I want to use glamor from the xorg-server tree. So, I build and install xorg (with the --enable-glamor option), then after this I build and install the xf86-video-ati driver. But what is strange, is that as you can see before, a libglamoregl.so shared library is required when I type startx. Why? I have said that I would like to use the glamor from the xorg-server tree, so I have not a libglamoregl.so installed file. Indeed, the libglamoregl.so file is provided by glamor from the glamor tree only. Are you agree? No, xserver with --enable-glamor also produces libglamoregl.so. It sounds like either something went wrong building xserver with --enable-glamor, or maybe you didn't specify --prefix=/usr for the xserver build, so it was installed to /usr/local/. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
On 07.08.2014 11:37, Russ Whitaker wrote: On Thu, 7 Aug 2014, YuGiOhJCJ Mailing-List wrote: Here is the exact configure line I have used: ./configure --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --mandir=/usr/man --docdir=/usr/doc/mesa-10.0.2 --with-dri-driverdir=/usr/lib/xorg/modules/dri --with-dri-drivers=i915,i965 --enable-shared-glapi --with-egl-platforms=drm --with-gallium-drivers=radeonsi ___ Isn't a i915 a Intel product and radeon a amd product? The i9xx drivers are indeed useless on YuGiOhJCJ's system, but building them shouldn't hurt anything. YuGiOhJCJ, the latest Mesa configure options you posted are inconsistent with the failure shown in http://pastebin.com/raw.php?i=AwPnpSJ7 . Please double- and triple-check that you're actually using the self-built binaries, and that those binaries correspond to the latest configure options. If the problem persists, please provide the current failure output, preferably with the EGL_LOG_LEVEL=debug environment variable set for the Xorg process. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
- xorg-server-1.16.0
- glamor-egl-0.6.0
With xserver 1.16.0 or later, you should use glamor from the xserver
tree, not from the separate glamor tree.
Yes, for xorg-server-1.16.0, no problem I can use the embedded glamor.
When I am compiling xorg-server-1.16.0, I do:
$ ./configure --prefix=/usr --libdir=/usr/lib --sysconfdir=/etc
--localstatedir=/var --infodir=/usr/info --mandir=/usr/man --disable-static
--with-pic --with-int10=x86emu --with-default-font-path=${DEF_FONTPATH}
--with-module-dir=/usr/lib/xorg/modules --with-xkb-path=/etc/X11/xkb
--with-xkb-output=/var/lib/xkb --enable-config-udev --disable-config-hal
--enable-glamor
I think that the --enable-glamor option means I will use the
xorg-server-1.16.0 embedded (internal) glamor version, isn't it?
Now, the problem is that without the external glamor, I got an error from the
radeon driver:
[ 44144.759] (EE) RADEON(0): glamor not available
And I again no have 3d acceleration:
[ 44144.801] (WW) RADEON(0): Direct rendering disabled
The full log is here:
http://pastebin.com/a51DRWg6
Why I have no 3D acceleration please?
___
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: %(user_address)s
Re: Am I using the ati or vesa driver?
On 07.08.2014 20:52, YuGiOhJCJ Mailing-List wrote:
- xorg-server-1.16.0
- glamor-egl-0.6.0
With xserver 1.16.0 or later, you should use glamor from the xserver
tree, not from the separate glamor tree.
Yes, for xorg-server-1.16.0, no problem I can use the embedded glamor.
When I am compiling xorg-server-1.16.0, I do:
$ ./configure --prefix=/usr --libdir=/usr/lib --sysconfdir=/etc
--localstatedir=/var --infodir=/usr/info --mandir=/usr/man --disable-static
--with-pic --with-int10=x86emu --with-default-font-path=${DEF_FONTPATH}
--with-module-dir=/usr/lib/xorg/modules --with-xkb-path=/etc/X11/xkb
--with-xkb-output=/var/lib/xkb --enable-config-udev --disable-config-hal
--enable-glamor
I think that the --enable-glamor option means I will use the
xorg-server-1.16.0 embedded (internal) glamor version, isn't it?
If you don't overwrite libglamoregl.so from the xserver tree with that
from the glamor tree, yes.
Note that you also need to rebuild xf86-video-ati against glamor from the
xserver tree.
Now, the problem is that without the external glamor, I got an error from the
radeon driver:
[ 44144.759] (EE) RADEON(0): glamor not available
And I again no have 3d acceleration:
[ 44144.801] (WW) RADEON(0): Direct rendering disabled
The full log is here:
http://pastebin.com/a51DRWg6
(II) Loading sub module glamoregl
(II) LoadModule: glamoregl
(WW) Warning, couldn't open module glamoregl
(II) UnloadModule: glamoregl
(II) Unloading glamoregl
(EE) RADEON: Failed to load module glamoregl (module does not exist, 0)
Looks like libglamoregl.so isn't installed, at least not in
/usr/lib/xorg/modules.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
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: %(user_address)s
Re: Am I using the ati or vesa driver?
On Thu, 7 Aug 2014, YuGiOhJCJ Mailing-List wrote: Here is the exact configure line I have used: ./configure --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --mandir=/usr/man --docdir=/usr/doc/mesa-10.0.2 --with-dri-driverdir=/usr/lib/xorg/modules/dri --with-dri-drivers=i915,i965 --enable-shared-glapi --with-egl-platforms=drm --with-gallium-drivers=radeonsi ___ Isn't a i915 a Intel product and radeon a amd product? Russ ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
But I see a last problem: I have no 3d acceleration! As you can see here: $ cat /var/log/Xorg.0.log | grep Direct [ 7567.271] (WW) RADEON(0): Direct rendering disabled The full xorg log is available here: http://pastebin.com/hSKjXsvL Do you know how to have 3d acceleration please? To overcome http://pastebin.com/raw.php?i=AwPnpSJ7 which you pasted on IRC, you need to compile Mesa with: --with-egl-platforms=drm Are you speaking about the segmentation fault + backtrace problem? I have built mesa-10.0.2 with the --with-egl-platforms=drm option but I have again this segmentation fault + backtrace problem. It does not solved this problem. Here is the exact configuration line I have used: ./configure --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --mandir=/usr/man --docdir=/usr/doc/mesa-10.0.2 --with-dri-driverdir=/usr/lib/xorg/modules/dri --with-dri-drivers=i915,i965 --enable-shared-glapi --with-egl-platforms=drm I am building and installing packages in this order: - libdrm-2.4.56 - mesa-10.0.2 - mesa-demos-8.1.0 - fontsproto-2.1.3 - glproto-1.4.17 - libepoxy-1.2 - xextproto-7.3.0 - xproto-7.0.26 - xtrans-1.3.4 - xorg-server-1.16.0 - glamor-egl-0.6.0 - xf86-video-ati-7.4.0 - xf86-video-intel-2.99.912 - xf86-video-vesa-2.3.3 Anyway, if I keep the official packages from Slackware 14.1, I have not this segmentation fault + backtrace problem. So, currently I am using: - libdrm-2.4.46 - mesa-9.1.7 - mesa-demos-8.1.0 - fontsproto-2.1.2 - glproto-1.4.16 - libepoxy-1.2 - xextproto-7.2.1 - xproto-7.0.24 - xtrans-1.2.7 - xorg-server-1.14.3 - glamor-egl-0.6.0 - xf86-video-ati-7.2.0 - xf86-video-intel-2.21.15 - xf86-video-vesa-2.3.3 In this second case, the problem is that I have no direct rendering. As you can see here: $ cat /var/log/Xorg.0.log | grep Direct [ 7567.271] (WW) RADEON(0): Direct rendering disabled The full xorg log is available here: http://pastebin.com/hSKjXsvL Maybe, it is just a permission problem, a xorg configuration problem, or something like that. What can I do to get direct rendering please? ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
On 05.08.2014 23:10, YuGiOhJCJ Mailing-List wrote: But I see a last problem: I have no 3d acceleration! As you can see here: $ cat /var/log/Xorg.0.log | grep Direct [ 7567.271] (WW) RADEON(0): Direct rendering disabled The full xorg log is available here: http://pastebin.com/hSKjXsvL Do you know how to have 3d acceleration please? To overcome http://pastebin.com/raw.php?i=AwPnpSJ7 which you pasted on IRC, you need to compile Mesa with: --with-egl-platforms=drm Are you speaking about the segmentation fault + backtrace problem? I have built mesa-10.0.2 with the --with-egl-platforms=drm option but I have again this segmentation fault + backtrace problem. It does not solved this problem. Apart from what Alex added, make sure the relevant binaries get rebuilt after you change the parameters passed to configure, in the worst case by running 'make clean' first, and that the binaries you compile are actually being used. If the problem persists, please provide a new log file. - xorg-server-1.16.0 - glamor-egl-0.6.0 With xserver 1.16.0 or later, you should use glamor from the xserver tree, not from the separate glamor tree. Anyway, if I keep the official packages from Slackware 14.1, I have not this segmentation fault + backtrace problem. [...] In this second case, the problem is that I have no direct rendering. As you can see here: $ cat /var/log/Xorg.0.log | grep Direct [ 7567.271] (WW) RADEON(0): Direct rendering disabled I suspect some of the older components are just too old to support your GPU. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
On Thu, 31 Jul 2014 23:14:34 +0900 Michel Dänzer mic...@daenzer.net wrote: On 31.07.2014 19:47, YuGiOhJCJ Mailing-List wrote: I give you my full Xorg.0.log here: http://pastebin.com/fsPBgt5P If you find an interesting line telling me what driver I am using please highlight it for me. The radeon driver fails to initialize because of this: [ 1684.773] (II) [KMS] drm report modesetting isn't supported. Check the dmesg output for why the radeon kernel driver isn't active. Indeed, this problem is because my radeon module is not loaded: $ lsmod | grep radeon So, I load it: $ sudo modprobe radeon Then after it I restart X, then I got: $ sudo dmesg | grep drm [ 5516.131529] [drm] Initialized drm 1.1.0 20060810 [ 5516.191147] [drm] radeon kernel modesetting enabled. So, it seems to be good now. No, there should be a lot more output. I suspect the kernel is too old to support your Kabini GPU. Indeed, my kernel was too old. I have upgraded from linux-3.10.17 to linux-3.15.8 and now it works: $ sudo dmesg | grep drm [7.256525] [drm] Initialized drm 1.1.0 20060810 [7.356838] [drm] radeon kernel modesetting enabled. [7.359272] [drm] initializing kernel modesetting (KABINI 0x1002:0x9839 0x1043:0x141D). [7.359484] [drm] register mmio base: 0xFEB0 [7.359607] [drm] register mmio size: 262144 [7.359781] [drm] doorbell mmio base: 0xD000 [7.359903] [drm] doorbell mmio size: 8388608 [7.360705] [drm] Detected VRAM RAM=512M, BAR=256M [7.360882] [drm] RAM width 128bits DDR [7.361827] [drm] radeon: 512M of VRAM memory ready [7.361951] [drm] radeon: 1024M of GTT memory ready. [7.362102] [drm] Loading KABINI Microcode [7.444224] [drm] Internal thermal controller without fan control [7.445271] [drm] radeon: dpm initialized [ 39.111953] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 39.134989] [drm] PCIE GART of 1024M enabled (table at 0x00277000). [ 39.139336] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 39.139466] [drm] Driver supports precise vblank timestamp query. [ 39.139855] [drm] radeon: irq initialized. [ 39.143992] [drm] ring test on 0 succeeded in 3 usecs [ 39.144211] [drm] ring test on 1 succeeded in 3 usecs [ 39.144368] [drm] ring test on 2 succeeded in 3 usecs [ 39.144825] [drm] ring test on 3 succeeded in 3 usecs [ 39.144964] [drm] ring test on 4 succeeded in 2 usecs [ 39.201193] [drm] ring test on 5 succeeded in 2 usecs [ 39.221352] [drm] UVD initialized successfully. [ 39.221990] [drm] ib test on ring 0 succeeded in 0 usecs [ 39.222412] [drm] ib test on ring 1 succeeded in 0 usecs [ 39.222815] [drm] ib test on ring 2 succeeded in 0 usecs [ 39.223238] [drm] ib test on ring 3 succeeded in 0 usecs [ 39.223653] [drm] ib test on ring 4 succeeded in 0 usecs [ 39.244927] [drm] ib test on ring 5 succeeded [ 39.282221] [drm] radeon atom DIG backlight initialized [ 39.282369] [drm] Radeon Display Connectors [ 39.282497] [drm] Connector 0: [ 39.282623] [drm] LVDS-1 [ 39.282746] [drm] HPD1 [ 39.282873] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [ 39.283071] [drm] Encoders: [ 39.283217] [drm] LCD1: INTERNAL_UNIPHY [ 39.283345] [drm] Connector 1: [ 39.283470] [drm] HDMI-A-1 [ 39.283593] [drm] HPD2 [ 39.283717] [drm] DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c [ 39.283915] [drm] Encoders: [ 39.284040] [drm] DFP1: INTERNAL_UNIPHY [ 39.284166] [drm] Connector 2: [ 39.284301] [drm] VGA-1 [ 39.284427] [drm] DDC: 0x65c0 0x65c0 0x65c4 0x65c4 0x65c8 0x65c8 0x65cc 0x65cc [ 39.284626] [drm] Encoders: [ 39.284751] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 39.386891] [drm] fb mappable at 0xC047B000 [ 39.387031] [drm] vram apper at 0xC000 [ 39.387156] [drm] size 4325376 [ 39.387287] [drm] fb depth is 24 [ 39.387411] [drm]pitch is 5632 [ 39.387731] fbcon: radeondrmfb (fb0) is primary device [ 39.440530] radeon :00:01.0: fb0: radeondrmfb frame buffer device [ 39.453620] [drm] Initialized radeon 2.38.0 20080528 for :00:01.0 on minor 0 Now, all my previous problems are solved: - 1 screen only used (the external VGA screen): solved! (the two screens are working together) - the font is too big: solved! (the font size is normal) - the xrandr command tells me Failed to get size of gamma for output default: solved! (this message is not displayed anymore) But I see a last problem: I have no 3d acceleration! As you can see here: $ cat /var/log/Xorg.0.log | grep Direct [ 7567.271] (WW) RADEON(0): Direct rendering disabled The full xorg log is available here: http://pastebin.com/hSKjXsvL Do you know how to have 3d acceleration please? Thank you. Best regards. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info:
Re: Am I using the ati or vesa driver?
On 04.08.2014 21:03, YuGiOhJCJ Mailing-List wrote: But I see a last problem: I have no 3d acceleration! As you can see here: $ cat /var/log/Xorg.0.log | grep Direct [ 7567.271] (WW) RADEON(0): Direct rendering disabled The full xorg log is available here: http://pastebin.com/hSKjXsvL Do you know how to have 3d acceleration please? To overcome http://pastebin.com/raw.php?i=AwPnpSJ7 which you pasted on IRC, you need to compile Mesa with: --with-egl-platforms=drm -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
[...] So, I think that I am using the vesa Xorg driver for generic VESA video cards instead of the ati video driver. How to be sure about that? Have a look at Xorg logs, usually /var/log/Xorg.0.log. -- Yeah, but it seems to load both drivers (and other drivers too): $ cat /var/log/Xorg.0.log | grep LoadModule [...] [ 1684.745] (II) LoadModule: ati [ 1684.746] (II) LoadModule: radeon [ 1684.748] (II) LoadModule: vesa [ 1684.749] (II) LoadModule: fbdev [...] I give you my full Xorg.0.log here: http://pastebin.com/fsPBgt5P If you find an interesting line telling me what driver I am using please highlight it for me. The radeon driver fails to initialize because of this: [ 1684.773] (II) [KMS] drm report modesetting isn't supported. Check the dmesg output for why the radeon kernel driver isn't active. Indeed, this problem is because my radeon module is not loaded: $ lsmod | grep radeon So, I load it: $ sudo modprobe radeon Then after it I restart X, then I got: $ sudo dmesg | grep drm [ 5516.131529] [drm] Initialized drm 1.1.0 20060810 [ 5516.191147] [drm] radeon kernel modesetting enabled. So, it seems to be good now. But I think I am again using vesa drivers because: $ cat /var/log/Xorg.0.log | grep LoadModule [ 6993.222] (II) LoadModule: glx [ 6993.249] (II) LoadModule: ati [ 6993.251] (II) LoadModule: radeon [ 6993.258] (II) LoadModule: vesa [ 6993.260] (II) LoadModule: modesetting [ 6993.267] (II) LoadModule: fbdev [ 6993.298] (II) LoadModule: vbe [ 6993.299] (II) LoadModule: int10 [ 6993.370] (II) LoadModule: ddc [ 6993.476] (II) LoadModule: shadow [ 6993.477] (II) LoadModule: fb [ 6993.480] (II) LoadModule: int10 [ 6995.208] (II) LoadModule: evdev This is my new full Xorg.0.log file: http://pastebin.com/krvwi0rd Do you see why I am on vesa instead of ati? ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
On 2014-07-31 12:47 (GMT+0200) YuGiOhJCJ Mailing-List composed: ... I give you my full Xorg.0.log here: http://pastebin.com/fsPBgt5P ... problem is because my radeon module is not loaded: $ lsmod | grep radeon So, I load it: $ sudo modprobe radeon ... This is my new full Xorg.0.log file: http://pastebin.com/krvwi0rd Do you see why I am on vesa instead of ati? I wonder if https://bugs.mageia.org/show_bug.cgi?id=13158 sheds any light on the reason. -- 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: %(user_address)s
Am I using the ati or vesa driver?
Hello, My computer is an ASUS x102ba [1]. When I type: $ startx I see that my display is strange: - 1 screen only used (the external VGA screen) - the font is too big - the xrandr command tells me Failed to get size of gamma for output default So, I think that I am using the vesa Xorg driver for generic VESA video cards instead of the ati video driver. How to be sure about that? Thank you. Best regards. [1] http://www.asus.com/Notebooks_Ultrabooks/X102BA/specifications/ ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
Dnia środa, 30 lipca 2014 14:52:47 YuGiOhJCJ Mailing-List pisze: [...] So, I think that I am using the vesa Xorg driver for generic VESA video cards instead of the ati video driver. How to be sure about that? Have a look at Xorg logs, usually /var/log/Xorg.0.log. -- Łukasz Maśko_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające Nie umiem zainstalować Debiana ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
[...] So, I think that I am using the vesa Xorg driver for generic VESA video cards instead of the ati video driver. How to be sure about that? Have a look at Xorg logs, usually /var/log/Xorg.0.log. -- Yeah, but it seems to load both drivers (and other drivers too): $ cat /var/log/Xorg.0.log | grep LoadModule [...] [ 1684.745] (II) LoadModule: ati [ 1684.746] (II) LoadModule: radeon [ 1684.748] (II) LoadModule: vesa [ 1684.749] (II) LoadModule: fbdev [...] I give you my full Xorg.0.log here: http://pastebin.com/fsPBgt5P If you find an interesting line telling me what driver I am using please highlight it for me. ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
Dnia środa, 30 lipca 2014 15:58:22 YuGiOhJCJ Mailing-List pisze: [...] So, I think that I am using the vesa Xorg driver for generic VESA video cards instead of the ati video driver. How to be sure about that? Have a look at Xorg logs, usually /var/log/Xorg.0.log. Yeah, but it seems to load both drivers (and other drivers too): $ cat /var/log/Xorg.0.log | grep LoadModule [...] [ 1684.745] (II) LoadModule: ati [ 1684.746] (II) LoadModule: radeon [ 1684.748] (II) LoadModule: vesa [ 1684.749] (II) LoadModule: fbdev [...] I give you my full Xorg.0.log here: http://pastebin.com/fsPBgt5P If you find an interesting line telling me what driver I am using please highlight it for me. You're deffinitely using the vesa driver. The radeon driver is loaded, but then the vesa driver is initialized as first and it takes control over your card, so finally, according to line #1700, the radeon driver is unloaded: [ 1684.950] (II) UnloadModule: radeon I'd suggest, you should either remove the vesa driver from your system and try then. Writing a proper config file would also do the trick. -- Łukasz Maśko_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające Nie umiem zainstalować Debiana ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
On 30.07.2014 22:58, YuGiOhJCJ Mailing-List wrote: [...] So, I think that I am using the vesa Xorg driver for generic VESA video cards instead of the ati video driver. How to be sure about that? Have a look at Xorg logs, usually /var/log/Xorg.0.log. -- Yeah, but it seems to load both drivers (and other drivers too): $ cat /var/log/Xorg.0.log | grep LoadModule [...] [ 1684.745] (II) LoadModule: ati [ 1684.746] (II) LoadModule: radeon [ 1684.748] (II) LoadModule: vesa [ 1684.749] (II) LoadModule: fbdev [...] I give you my full Xorg.0.log here: http://pastebin.com/fsPBgt5P If you find an interesting line telling me what driver I am using please highlight it for me. The radeon driver fails to initialize because of this: [ 1684.773] (II) [KMS] drm report modesetting isn't supported. Check the dmesg output for why the radeon kernel driver isn't active. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
On 07/30/14 12:52 PM, Linda A. Walsh wrote: Łukasz Maśko wrote: $ cat /var/log/Xorg.0.log | grep LoadModule [...] [ 1684.745] (II) LoadModule: ati [ 1684.746] (II) LoadModule: radeon [ 1684.748] (II) LoadModule: vesa [ 1684.749] (II) LoadModule: fbdev You're deffinitely using the vesa driver. The radeon driver is loaded, but then the vesa driver is initialized as first and it takes control over your card, so finally, according to line #1700, the radeon driver is unloaded: Side question -- Was it unloaded because Vesa loaded first or because the radeon driver wasn't able to talk to its kernel component? I.e. Does it pick drivers based on best match or first match? It goes through in what in thinks is the best order and tries until one works. As you can see above, it tried failed with ati/radeon before falling back to vesa. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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: %(user_address)s
Re: Am I using the ati or vesa driver?
Łukasz Maśko wrote: $ cat /var/log/Xorg.0.log | grep LoadModule [...] [ 1684.745] (II) LoadModule: ati [ 1684.746] (II) LoadModule: radeon [ 1684.748] (II) LoadModule: vesa [ 1684.749] (II) LoadModule: fbdev You're deffinitely using the vesa driver. The radeon driver is loaded, but then the vesa driver is initialized as first and it takes control over your card, so finally, according to line #1700, the radeon driver is unloaded: Side question -- Was it unloaded because Vesa loaded first or because the radeon driver wasn't able to talk to its kernel component? I.e. Does it pick drivers based on best match or first match? ___ 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: %(user_address)s
Re: Wrong virtualX when using vesa driver with no shadowFB
On Fri, 2014-02-14 at 11:47 +, Stefano Panella wrote: The reason why the problem happen is that in the vesa driver, as it is now, has no way to detect the needed alignment of the framebuffer unless using the shadowFB. I'd say more like doesn't than has no way to. The VBE (as I understand) has only two ways to say the driver what the stride should be for a given mode: 1) mode-BytesPerScanline 2) VBEGetLogicalScanline() There's also mode-XCharSize, which in the example you give is 8; which would explain things, since 1366 % 8 != 0. But BytesPerScanline is probably a more obvious thing to look at. The second information is never used since VESASetMode() is only using VBESetLogicalScanline() and is never checking if the value was accepted from the HW or was rounded up and it looks like for mode 1366x768 BytesPerScanline=5504, pScrn-displayWidth if 1368, which results in a scanline of 5472, which will result in a distorted image. if (data-data-XResolution != pScrn-displayWidth) VBESetLogicalScanline(pVesa-pVbe, pScrn-displayWidth); The spec say that the HW could round up the value written with VBESetLogicalScanline() (and our emulation is doing so) so I think it would be appropriate to call VBEGetLogicalScanline() after to check if the value was accepted as it was or if it was rounded up, in which case pScrn-displayWidth and pScrn-virtualX should be updated accordingly. If my understanding is correct, this would explain why when we disable shadowFB the actual stride is wrong. If you can confirm my reasoning is correct, I would be happy to post a patch to fix this in case shadowFB is not used. I think your understanding is correct. Sorry for being slow to respond to this, and thanks for investigating it! - ajax ___ 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
Wrong virtualX when using vesa driver with no shadowFB
Hi all,
I have a question regarding the vesa driver stride when using horizontal
resolution not multiple which do not play nicely with HW constrains for
the stride.
I am working in a Xen/qemu environment where we emulate a Bochs VBE.
Our linux guests will usually use the vesa Xorg driver.
The problem I have noticed happen when we do not use the shadowFB and we
have a mode like 1366x768 with stride of 5504 which needs to be 64 bytes
aligned since we are using the GPU to scan the framebuffer of the guest
(this could not be a limitation for different qemu backends).
The reason why the problem happen is that in the vesa driver, as it is
now, has no way to detect the needed alignment of the framebuffer unless
using the shadowFB.
The VBE (as I understand) has only two ways to say the driver what the
stride should be for a given mode:
1) mode-BytesPerScanline
2) VBEGetLogicalScanline()
at the moment, in the vesa driver, the first information is only used
when using the shadowFB:
pMode = pScrn-modes;
do {
mode = ((VbeModeInfoData*)pMode-Private)-data;
if (mode-BytesPerScanline pVesa-maxBytesPerScanline) {
pVesa-maxBytesPerScanline = mode-BytesPerScanline;
}
pMode = pMode-next;
} while (pMode != pScrn-modes);
where
pVesa-maxBytesPerScanline
gets only used in VESAWindowLinear()
VESAWindowLinear(ScreenPtr pScreen, CARD32 row, CARD32 offset, int mode,
CARD32 *size, void *closure)
{
ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
VESAPtr pVesa = VESAGetRec(pScrn);
*size = pVesa-maxBytesPerScanline;
return ((CARD8 *)pVesa-base + row * pVesa-maxBytesPerScanline +
offset);
}
and as I said VESAWindowLinear() is used only if shadowFB is on
The second information is never used since VESASetMode() is only using
VBESetLogicalScanline() and is never checking if the value was accepted
from the HW or was rounded up and it looks like for mode 1366x768
BytesPerScanline=5504, pScrn-displayWidth if 1368, which results in a
scanline of 5472, which will result in a distorted image.
if (data-data-XResolution != pScrn-displayWidth)
VBESetLogicalScanline(pVesa-pVbe, pScrn-displayWidth);
The spec say that the HW could round up the value written with
VBESetLogicalScanline() (and our emulation is doing so) so I think it
would be appropriate to call VBEGetLogicalScanline() after to check if
the value was accepted as it was or if it was rounded up, in which case
pScrn-displayWidth and pScrn-virtualX should be updated accordingly.
If my understanding is correct, this would explain why when we disable
shadowFB the actual stride is wrong.
If you can confirm my reasoning is correct, I would be happy to post a
patch to fix this in case shadowFB is not used.
Thanks for your time,
Stefano
This is the mode creating problems:
[99.232] *Mode: 156 (1366x768)
[99.232]ModeAttributes: 0x9b
[99.232]WinAAttributes: 0x7
[99.232]WinBAttributes: 0x0
[99.232]WinGranularity: 64
[99.232]WinSize: 64
[99.232]WinASegment: 0xa000
[99.232]WinBSegment: 0x0
[99.232]WinFuncPtr: 0xc000948a
[99.232]BytesPerScanline: 5504
[99.232]XResolution: 1366
[99.232]YResolution: 768
[99.232]XCharSize: 8
[99.232]YCharSize: 16
[99.232]NumberOfPlanes: 1
[99.232]BitsPerPixel: 32
[99.232]NumberOfBanks: 1
[99.232]MemoryModel: 6
[99.232]BankSize: 0
[99.232]NumberOfImages: 2
[99.232]RedMaskSize: 8
[99.232]RedFieldPosition: 16
[99.232]GreenMaskSize: 8
[99.232]GreenFieldPosition: 8
[99.232]BlueMaskSize: 8
[99.232]BlueFieldPosition: 0
[99.232]RsvdMaskSize: 8
[99.232]RsvdFieldPosition: 24
[99.232]DirectColorModeInfo: 2
[99.232]PhysBasePtr: 0xf000
___
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
vesa driver screen dimming problem
From time to time, I find myself having to use the xf86-video-vesa driver when my xf86-video-r128 driver fails after an upgrade (I'll make a separate post about that). When I use the vesa driver, I have a problem with my X11 screen going into what I call dim-mode, where the graphic screen is very dim and hard to read. The dim-mode problem does not effect the tty screen. Once X11 goes into dim-mode the only way I found to fix it is to, shut down the Xserver (thus killing my desktop) and restart the Xserver. I am old school, I log into my session in text mode, then I use startx to start my desktop. I first noticed the problem about a year ago, but when I changed to a working xf86-video-r128 driver, I no longer had to deal with the issue. I have only tried the vesa driver with one computer that has a mo-bo video adapter. Dim-mode can be triggered on one of two ways. One way is to ctrl-alt-function to a tty screen, then ctrl-alt-function back to the X11 screen. This causes the Xserver to go into dim-mode. Games that uses SDK will cause X11 to go into dim mode instantly. Also mplayer will cause dim-mode after a few seconds of play. No matter how the Xserver gets into dim-mode, the only way to get out of it is to restart Xserver, switching back and forth to ttys does not fix the problem. Looking at Xorg.0.log, I can see that no additional info is added to the log file at the time the Xserver goes into dim-mode. As a test I started :0 and it went dim when I went to a tty then back to :0. I then started :1 and it was fine. I switched from :1 to :0 to find that :0 was still dim. I then switched back to :1 and it too was then dim. I am wondering if the problem is due to a bug in the xf86-video-vesa driver, or is there is a setting a can use to avoid this problem. Excerpt from /var/log/Xorg.0.log X.Org X Server 1.14.3 Module vesa: vendor=X.Org Foundation compiled for 1.14.3, module version = 2.3.3 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 14.1 /var/log/Xorg.0.log - http://pastebin.com/DHHxVCbv FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium ___ 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: %(user_address)s
Help on under the hood article on why openSUSE xorg could did not default to vesa driver but instead loaded fbdev device limited to 800x600 in Hyper-V virtual machine
I am trying to analyse the Xorg.0.log in /var/log on an openSUSE 12.3 install in a Hyper-V virtual machine. CentOS 6.3 and Ubuntu 12.04 LTS both loaded fine, but for some reason the vesa driver for the virtualized graphics card (Microsoft graphics card) did not load only the primitive fbdev and fbdevhw device loaded, limiting the X screen to 800x600 mode. There is a fix a fellow on the openSUSE hardware forum suggested, but I wanted to create an article to address the whys and wherefores of why this happened to help people with the fix foremost, give a summary explanation secondly and then give and in-depth analysis of why it happened. So far, I have fumbled through the Xorg.0.log and done the best I could, but it is a work in progress. Any help with this article would be appreciated: http://www.sanbarcomputing.com/?p=2033 I am hoping it will not only educate me in the writing, but educate others interested in this subject and help those who need the fix as well. Thanks in advance! ** *Scott Sanbar, Chief Engineer, Sanbar Computing * scott.san...@gmail.com | http://www.sanbarcomputing.com | (405) 227-4724 Personal Blog: http://www.aeoril.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
Help on under the hood article on why openSUSE xorg could did not default to vesa driver but instead loaded fbdev device limited to 800x600 in Hyper-V virtual machine
I am trying to analyse the Xorg.0.log in /var/log on an openSUSE 12.3 install in a Hyper-V virtual machine. CentOS 6.3 and Ubuntu 12.04 LTS both loaded fine, but for some reason the vesa driver for the virtualized graphics card (Microsoft graphics card) did not load only the primitive fbdev and fbdevhw device loaded, limiting the X screen to 800x600 mode. There is a fix a fellow on the openSUSE hardware forum suggested, but I wanted to create an article to address the whys and wherefores of why this happened to help people with the fix foremost, give a summary explanation secondly and then give and in-depth analysis of why it happened. So far, I have fumbled through the Xorg.0.log and done the best I could, but it is a work in progress. Any help with this article would be appreciated: http://www.sanbarcomputing.com/?p=2033 I am hoping it will not only educate me in the writing, but educate others interested in this subject and help those who need the fix as well. Thanks in advance! ** *Scott Sanbar, Chief Engineer, Sanbar Computing * scott.san...@gmail.com | http://www.sanbarcomputing.com | (405) 227-4724 Personal Blog: http://www.aeoril.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
vesa driver and rotation via xrandr
Hi all I have googled around, asked on the xorg ml and here I am :) To make it short - I need to use xrandr to rotate the screen when the vesa driver is used. I think that I need to use ShadowFB to make it possible in the first step. But what needs to be done to support xrandr rotation stuff in ShadowFB? Where do I start to program/hack on it? Or is xrandr stuff already supported? so many questions, but I am new to xorg development ;) thanks --- Christian Gmeiner, MSc ___ 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
VESA driver
Hi, it appears to me that xorg-driver-vesa-2.3.0 does not compile with the latest X, and it hasn't been updated since 2010. Are there any plans to release a new version or is there another driver that should be used instead as a generic fallback? ___ 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: VESA driver
On Thu, 2012-03-22 at 13:38 +0100, Henrik Pauli wrote: it appears to me that xorg-driver-vesa-2.3.0 does not compile with the latest X, and it hasn't been updated since 2010. Are there any plans to release a new version or is there another driver that should be used instead as a generic fallback? The version in git works fine. Fair point though, I'll release a new one later today. - ajax signature.asc Description: This is a digitally signed message part ___ 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: VESA driver
On Thu, 22 Mar 2012 09:48:27 -0400
Adam Jackson a...@redhat.com wrote:
On Thu, 2012-03-22 at 13:38 +0100, Henrik Pauli wrote:
it appears to me that xorg-driver-vesa-2.3.0 does not compile with
the latest X, and it hasn't been updated since 2010. Are there any
plans to release a new version or is there another driver that
should be used instead as a generic fallback?
The version in git works fine. Fair point though, I'll release a new
one later today.
Very nice; thanks.
Unless something changed since last week (I'll admit to not having
checked), the following drivers will build fine using either git
versions or cherry-picked patches from git:
xf86-video-{apm,ast,ati,chips,cirrus,i128,rendition,siliconmotion,vesa}
The following drivers won't build at all against latest xserver:
xf86-video-{sisusb,tdfx,trident,tseng,xgi}
-RW
signature.asc
Description: PGP signature
___
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
Bug#451511: xserver-xorg-video-ati: The ati driver unexpectedly seems to perform worse than the VESA driver
Brice Goglin wrote: Helge Hafting wrote: Minor severity as the driver works as intended. I find the low performance odd though. If the accelerator hardware is slower than VESA for some operations, then surely the unaccelerated VESA way could be used for those things. So it seems to me it doesn't need to be slower in any cases. My testcase is to play the game cuyo at levels 2 or 9. (package cuyo) This is a tetris-like 2D game. It updated the screen 10 times a second, and has a irritating failure mode: If it can't finish drawing in 1/10s, then it refuse to take input until the drawing queue clears. So it may break very noticeably when there is too much animation going on. Now, perhaps that isn't the best way to design a game, but it shows a performance problem. The ati driver (and the NV driver) easily falls into this trap when there is lots of animation in the cuyo window. The game becomes quite unplayable. This simply doesn't happen with the VESA driver. CPU load stays below 25% always. The processor in this case is a 2.4GHz pentium-M, lspci shows: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] Another machine with a pci radeon 9200 SE and a 1.8GHz opteron shows the same problem. A third machine with a 1.8Ghz core duo and a nvidia card has this problem too, but of course that is a different package Can you try with Option AccelMethod EXA in the Device section of your xorg.conf? Thanks for the tip - this change made tremendous difference. Using the ATI driver, the game is now as snappy as VESA - and X probably respond better to bigger drawing jobs. The EXA option solved my problem completely. :-) Helge Hafting ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
