driver issueshttps://gitlab.freedesktop.org/groups/xorg/driver/-/issues2018-08-10T20:43:01Zhttps://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/1mga(4) man page is incomplete2018-08-10T20:43:01ZBugzilla Migration Usermga(4) man page is incomplete## Submitted by ATek
Assigned to **Xorg Project Team**
**[Link to original bug (#2038)](https://bugs.freedesktop.org/show_bug.cgi?id=2038)**
## Description
I've installed MDK10.1 with xorg server on a PC with Matrox G550 Dual Head...## Submitted by ATek
Assigned to **Xorg Project Team**
**[Link to original bug (#2038)](https://bugs.freedesktop.org/show_bug.cgi?id=2038)**
## Description
I've installed MDK10.1 with xorg server on a PC with Matrox G550 Dual Head.
I've a CRT on head 0 and LCD on head 1.
When linux start it use head 0 but when X server start head 0 and head 1 are
swapped. I've tried to swap "Screen 0" and "Screen 1" in Section "Device" for
device 1 and device 2 but no solution.
What can I do?
Thanxhttps://gitlab.freedesktop.org/xorg/driver/xf86-video-geode/-/issues/1AMD/NSC Geode driver integration2018-08-10T20:42:05ZBugzilla Migration UserAMD/NSC Geode driver integration## Submitted by ajax `@ajax`
Assigned to **Xorg Project Team**
**[Link to original bug (#2088)](https://bugs.freedesktop.org/show_bug.cgi?id=2088)**
## Description
The Geode series chips are embedded graphics solutions, formerly f...## Submitted by ajax `@ajax`
Assigned to **Xorg Project Team**
**[Link to original bug (#2088)](https://bugs.freedesktop.org/show_bug.cgi?id=2088)**
## Description
The Geode series chips are embedded graphics solutions, formerly from National
Semiconductor and currently sold by AMD. AMD has various X drivers for the
Geode series on its website:
http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_11363,00.html
There is also a Geode driver on the geode-0-0-1-branch of DRI's xc tree, last
touched by Alah Hourihane sometime in 2002.
There is already an nsc(4) driver in the tree, which supports much of the same
hardware (but perhaps not all). Someone should investigate AMD's drivers and,
if they provide any additional support, merge them to the tree.
### Blocking
* [Bug 1903](https://bugs.freedesktop.org/show_bug.cgi?id=1903)https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/1cyber9320 on the Thinkpad 365X[D] DSTN - "orange lines" and system crash/freeze2018-08-10T20:48:04ZBugzilla Migration Usercyber9320 on the Thinkpad 365X[D] DSTN - "orange lines" and system crash/freeze## Submitted by James
Assigned to **Egbert Eich**
**[Link to original bug (#2323)](https://bugs.freedesktop.org/show_bug.cgi?id=2323)**
## Description
The XFree86 trident driver has always had a problem with the Thinkpad 365XD Tri...## Submitted by James
Assigned to **Egbert Eich**
**[Link to original bug (#2323)](https://bugs.freedesktop.org/show_bug.cgi?id=2323)**
## Description
The XFree86 trident driver has always had a problem with the Thinkpad 365XD Trident
TGUI 9320 "Cyber" chipset interacting with IBM's DSTN 800x600 LCD. On startup, the
screen would only display two horizontal orange lines and "burn" the LCD, physically
damaging the display - with some recovery over time, as if each section of the dual
scan display had lost the vertical scan signal.
The traditional work-around has been to press Fn and F7, the LCD/external-monitor
switching function, after the X server is started. The result would be a normal
display after a few second delay. This was possible with the XFree86 SVGA driver
version 3.3.6 at least.
The new Xorg trident driver still shows the same problem with the burning orange
lines, but the "Fn and F7" hack has a problem - the system freezes / crashes
instantly. The laptop must be powered down to recover.
Starting with the external display, the situation is the same (without the horizontal
lines of course) - after the X server is started, the screen is blank, and screen
switching freezes / crashes the system, requiring a hard reset.
Starting with the dual display mode is again the same. Starting the X server leaves
both screens blank, with burning orange lines on the LCD. Screen switching to LCD-
only freezes / crashes the system.
Killing the X server without switching displays returns a blank virtual terminal that
can be recovered using "setfont". Leaving the X server for a virtual terminal first,
Fn F7 rotates through the displays normally. Changing back to the X server and,
again, using Fn F7 freezes / crashes the system.
I would infer that this system freeze problem has less to do with the blank X server
startup screen, and more to do with the interaction between the Thinkpad screen-
switching and the Xorg X server.
Trying different trident driver options seems to make no difference. Trying different
bpp options is slightly different. At 16 bpp, instead of 8 bpp - the 365XD has only
1MB of video ram and the driver insists on using a 1024 byte pitch - the X server
starts with a visible display on the left half, and blank or with half-hight vertical
lines on the right half of the LCD, and blank on the external display. Still, trying
the Fn F7 hack fails to switch screens, or, with the option "NoCyberShadow" suggested
in the trident man page, again the system freezes.
Now, the XFree86 version 4 driver has these same problems, so they are inherited.
Something was lost going from version 3 to version 4. What's different? Could
someone please take a look at this. This is a problem here because the vesa bios is
version 1.2 instead of the version 2 needed to use the vesa framebuffer driver.
BTW, the Linux "drivers/video/tridentfb" driver acts similarly, showing the burning
orange lines and blank screen on start up, and freezing the system with Fn F7.
Version: 6.8.1https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/2[MGA G450] Mouse cursor corrupted2018-08-10T20:43:04ZBugzilla Migration User[MGA G450] Mouse cursor corrupted## Submitted by Ralph Loader
Assigned to **Xorg Project Team**
**[Link to original bug (#2360)](https://bugs.freedesktop.org/show_bug.cgi?id=2360)**
## Description
Some mouse cursors are getting corrupted for me, typically appeari...## Submitted by Ralph Loader
Assigned to **Xorg Project Team**
**[Link to original bug (#2360)](https://bugs.freedesktop.org/show_bug.cgi?id=2360)**
## Description
Some mouse cursors are getting corrupted for me, typically appearing as a 64 x
64 pattern of vertical stripes (like a barcode).
Most mouse cursors are OK, it is only a few that are corrupted, e.g., those used
for:
The icon in the URL bar of mozilla firefox.
The drawing area of ggv (gnome's postscript viewer).
This is a MGA G450. Currently running Fedora rawhide:
$ rpm -q xorg-x11
xorg-x11-6.8.1.902-1
$ uname -a
Linux localhost 2.6.10-1.1063_FC4
The bug seems intermittent - sometimes when I reboot the problem disappears,
sometimes it re-appears.https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/3Matrox driver does not set correct refresh rates for second monitor after reb...2018-08-10T20:43:08ZBugzilla Migration UserMatrox driver does not set correct refresh rates for second monitor after reboot.## Submitted by Hal Engel
Assigned to **Xorg Project Team**
**[Link to original bug (#2779)](https://bugs.freedesktop.org/show_bug.cgi?id=2779)**
## Description
When I reboot my system the second monitor does not have the correct ...## Submitted by Hal Engel
Assigned to **Xorg Project Team**
**[Link to original bug (#2779)](https://bugs.freedesktop.org/show_bug.cgi?id=2779)**
## Description
When I reboot my system the second monitor does not have the correct refresh
rates. The monitor says refresh rates out of range and says the current setting
is 102KHz and 81Hz. I need 94KHz and 75Hz for this to work correctly. Both of
my monitors are identical and are setup the same in xorg.conf. If I restart X
then the second monitor is OK. It does this from both a cold boot and a warm boot.
Actual Results:
When X starts the second monitor reports that the refresh rates are out of range
with the values 102KHz and 81Hz. The correct refresh rates are 94KHz and 75Hz.
Expected Results:
Both monitors should have the correct refresh rates set and I should be able to
use the second display after a boot or reboot without having to restart X.
I have a Matrox G450 video card. I am running xorg 6.8.0-r4. I also tried xorg
6.8.2 but it had the same problem. I am running Gentoo 2004.3 on an amd64
machine in 64 bit mode.
Since I have a work around I have set the severity to minor. I posted this in
the Gentoo Bugzilla and they asked me to post it here.
Version: 6.8.0https://gitlab.freedesktop.org/xorg/driver/xf86-video-r128/-/issues/1[r128] XVideo broken with interlaced modeline2018-08-10T20:50:04ZBugzilla Migration User[r128] XVideo broken with interlaced modeline## Submitted by Cory Papenfuss
Assigned to **Xorg Project Team**
**[Link to original bug (#4587)](https://bugs.freedesktop.org/show_bug.cgi?id=4587)**
## Description
I've followed this problem from Redhat9 through FC4, and it has ...## Submitted by Cory Papenfuss
Assigned to **Xorg Project Team**
**[Link to original bug (#4587)](https://bugs.freedesktop.org/show_bug.cgi?id=4587)**
## Description
I've followed this problem from Redhat9 through FC4, and it has stayed
consistent. I use direct NTSC frequencies out of the VGA port for tvout. When
playing a video using XVideo extention, only the top half of the video plays,
but it takes up the full screen. At one point, (still XFree86-based distro) I
used the GATOS driver to fix the problem. Both the 'ati' and 'r128' driver
exhibit this problem on a r128 card. The Mach64 and radeon appear to work now
(with 6.8.2 at least).
Version: 6.8.2https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/2CyberBlade/xp4 Glowing White Screen modify xorg.conf to "vesa"2018-08-10T20:48:07ZBugzilla Migration UserCyberBlade/xp4 Glowing White Screen modify xorg.conf to "vesa"## Submitted by Ben Kevan
Assigned to **Alan Hourihane**
**[Link to original bug (#5215)](https://bugs.freedesktop.org/show_bug.cgi?id=5215)**
## Description
I have a Toshiba Tecra M1 and when X tries to load it becomes white and ...## Submitted by Ben Kevan
Assigned to **Alan Hourihane**
**[Link to original bug (#5215)](https://bugs.freedesktop.org/show_bug.cgi?id=5215)**
## Description
I have a Toshiba Tecra M1 and when X tries to load it becomes white and never
loads. Here is copy of the original device section xorg.conf
Section "Device"
BoardName "CyberBlade/xp4"
BusID "1:0:0"
Driver "trident"
Identifier "Device[0]"
Screen 0
VendorName "Trident"
EndSection
Once I modified it to:
Section "Device"
BoardName "CyberBlade/xp4"
BusID "1:0:0"
Driver "vesa"
Identifier "Device[0]"
Screen 0
VendorName "Trident"
EndSection
It would load and I can use the machine, just thought I would show you guys. Is
this fixed in a later version? How can I install a newer version? Thanks.
Version: 6.8.2https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/3overlay misalignment and "garbage" line on CyberBladeXP2018-08-10T20:48:14ZBugzilla Migration Useroverlay misalignment and "garbage" line on CyberBladeXP## Submitted by Philip Pemberton
Assigned to **Alan Hourihane**
**[Link to original bug (#5428)](https://bugs.freedesktop.org/show_bug.cgi?id=5428)**
## Description
System: Toshiba Satellite Pro 4600. 700MHz Coppermine Celeron, 25...## Submitted by Philip Pemberton
Assigned to **Alan Hourihane**
**[Link to original bug (#5428)](https://bugs.freedesktop.org/show_bug.cgi?id=5428)**
## Description
System: Toshiba Satellite Pro 4600. 700MHz Coppermine Celeron, 256MB RAM.
Trident CyberBladeXP chipset with 14" 1024x768 LCD.
OS: Fedora Core 4 i386 with latest updates (from "yum update") as of 2005-12-25
Xorg version:
When I play any video file in any application that uses Xv (Xvideo?) to output
video, a blue border (width varies dependent on screen BPP - two pixels for
16-bit, 3 pixels for 24-bit) is visible along the left hand side of the image,
and a single-pixel wide green line (colour varies and the line often has garbage
inside it) is visible along the bottom.
When the left-hand border is corrected (using the XvHsync and XvRskew Options),
it becomes apparent that two pixels from the LHS of the video have been moved
over to the RHS. They maintain the same pixel order, but are displaced one pixel
vertically upwards. It's always two pixels that get moved - the display BPP
setting does not affect it.
The "garbage line" along the bottom of the screen is not affected by setting
XvBskew to 1. It also only seems to appear in full-screen mode; the same colour
appears in the two pixels on the bottom row of the block that gets moved from
the left.
The Videolan "VLC" video player is very good at provoking these symptoms, it
seems, especially in Full Screen mode...
I would provide screenshots, but I have yet to find a method to capture decent
quality ones that include the overlay video. I will upload my xorg.conf and Xorg
startup log as soon as I fish them off the laptop's HDD.
Version: 6.8.2https://gitlab.freedesktop.org/xorg/driver/xf86-video-sis/-/issues/1Switching to text console and back hangs X server2018-08-10T20:47:08ZBugzilla Migration UserSwitching to text console and back hangs X server## Submitted by Pawel Salek
Assigned to **Xorg Project Team**
**[Link to original bug (#5842)](https://bugs.freedesktop.org/show_bug.cgi?id=5842)**
## Description
It appears that this is probably a bug in the SiS driver not
saving...## Submitted by Pawel Salek
Assigned to **Xorg Project Team**
**[Link to original bug (#5842)](https://bugs.freedesktop.org/show_bug.cgi?id=5842)**
## Description
It appears that this is probably a bug in the SiS driver not
saving/restoring properly. Switching the virtual console to text mode and back
leaves the Xorg process unresponsive and the screen white. This problem has
appearead in Fedora rawhide in the last month, I believe. The box as such is
alive and one can connect via ssh to it. See also
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180465 for the original report.
After the hang, the Xorg process gets stuck. It utilizes 100% CPU. When I
connect gdb to Xorg, I get following stack trace:
```
(gdb) where
#0 0x00000036286bd900 in __write_nocancel () from /lib64/libc.so.6
#1 0x0000003628667793 in _IO_new_file_write () from /lib64/libc.so.6
#2 0x0000003628668bef in _IO_new_file_xsputn () from /lib64/libc.so.6
#3 0x000000362865e89b in fwrite () from /lib64/libc.so.6
#4 0x00000000005666a2 in LogVWrite ()
#5 0x000000000056717d in LogVMessageVerb ()
#6 0x0000000000481f2c in xf86VDrvMsgVerb ()
#7 0x00002b59ab2893c2 in sisRestoreExtRegisterLock ()
from /usr/lib64/xorg/modules/drivers/sis_drv.so
#8 0x00002b59ab28b2f5 in sisSaveUnlockExtRegisterLock ()
from /usr/lib64/xorg/modules/drivers/sis_drv.so
#9 0x00002b59ab28f4d9 in SiS_SetSISTVedgeenhance ()
from /usr/lib64/xorg/modules/drivers/sis_drv.so
#10 0x00002b59ab29b3cd in SISAdjustFrame ()
from /usr/lib64/xorg/modules/drivers/sis_drv.so
#11 0x00002b59ab29b850 in SISAdjustFrame ()
from /usr/lib64/xorg/modules/drivers/sis_drv.so
#12 0x00002b59ab5fa69b in xf86ForceHWCursor ()
from /usr/lib64/xorg/modules/libramdac.so
#13 0x000000000047f7d1 in xf86InitFBManagerArea ()
#14 0x000000000048c152 in xf86XVScreenInit ()
#15 0x0000000000479714 in xf86Wakeup ()
#16 0x000000000044e2a5 in WakeupHandler ()
#17 0x0000000000559cb4 in WaitForSomething ()
#18 0x000000000044a33a in Dispatch ()
#19 0x0000000000432c95 in main ()
```
Version: 7.0.0https://gitlab.freedesktop.org/xorg/driver/xf86-video-savage/-/issues/1DRI functionality is not completely restored after software suspend2018-08-10T20:46:04ZBugzilla Migration UserDRI functionality is not completely restored after software suspend## Submitted by Slava Gorbunov
Assigned to **Tormod Volden**
**[Link to original bug (#6612)](https://bugs.freedesktop.org/show_bug.cgi?id=6612)**
## Description
After resuming from software suspend (which involves switching to te...## Submitted by Slava Gorbunov
Assigned to **Tormod Volden**
**[Link to original bug (#6612)](https://bugs.freedesktop.org/show_bug.cgi?id=6612)**
## Description
After resuming from software suspend (which involves switching to text VT and
back) DRI works only partialy. Simple applications (like glxgears or gl-117 (the
3d game with rather simple 3d graphics)) work well, but more complex
applications don't. For example, Blender doesn't draw labels on buttons, draws
some garbage instead of menus and outputs some garbage in the top left coner of
the screen (above all other windows). More complex 3d games (like tuxracer)
cause immediate lockup. Before suspending (and after restart of Xserver)
everything works well.
Version: 6.8.99.901 (6.9 RC1)https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/4Segfault when scrolling2018-08-10T20:48:17ZBugzilla Migration UserSegfault when scrolling## Submitted by Al Dimond
Assigned to **Xorg Project Team**
**[Link to original bug (#6625)](https://bugs.freedesktop.org/show_bug.cgi?id=6625)**
## Description
I have been getting fairly regular segfaults with xorg 6.9.0 under Fr...## Submitted by Al Dimond
Assigned to **Xorg Project Team**
**[Link to original bug (#6625)](https://bugs.freedesktop.org/show_bug.cgi?id=6625)**
## Description
I have been getting fairly regular segfaults with xorg 6.9.0 under FreeBSD
6-stable, using the Trident driver. Usually they occur when I'm dragging a
program's scroll bars; it happens especially when the program is being run
through ssh/X-tunneling, but has also occurred when using Firefox and Opera locally.
The log file doesn't tell me anything more than that the server received signal
11; I logged in remotely and got a backtrace using GDB, and here's where it gets
strange: the binaries I'm using right now don't appear to have debugging symbols
in them so I don't know exactly where this is but the backtrace is 1676 deep,
which caught my attention. Here is an excerpt:
```
Program received signal SIGSEGV, Segmentation fault.
0x2825b1b1 in ?? ()
(gdb) bt
#0 0x2825b1b1 in ?? ()
#1 0x00000000 in ?? ()
#2 0x00000000 in ?? ()
#3 0x08fb5a30 in ?? ()
#4 0x08fb5a30 in ?? ()
#5 0x00000000 in ?? ()
#6 0x08fb5000 in ?? ()
#7 0x00000008 in ?? ()
#8 0x00000005 in ?? ()
#9 0x00000010 in ?? ()
#10 0x00000000 in ?? ()
#11 0x00000000 in ?? ()
#12 0x282c44e4 in ?? ()
#13 0x081b0488 in ?? ()
#14 0x08fb5a30 in ?? ()
#15 0xbfbfe6b8 in ?? ()
#16 0x2825ba41 in ?? ()
#17 0x00000000 in ?? ()
#18 0x00000000 in ?? ()
#19 0x00000000 in ?? ()
#20 0x02fc0000 in ?? ()
#21 0x00000000 in ?? ()
#22 0x00000000 in ?? ()
#23 0x00000000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#24 0x00000000 in ?? ()
#25 0x00000000 in ?? ()
#26 0x00000000 in ?? ()
#27 0x00000000 in ?? ()
#28 0x00000000 in ?? ()
#29 0xbfbfe700 in ?? ()
#30 0x082d79c0 in ?? ()
#31 0xbfbfe668 in ?? ()
#32 0x0817cc5d in ?? ()
#33 0xbfbfe700 in ?? ()
#34 0x081c5cb0 in ?? ()
#35 0xbfbfe678 in ?? ()
#36 0x081af3a8 in ?? ()
#37 0x08220258 in ?? ()
#38 0x2879bff8 in ?? ()
#39 0xbfbfe698 in ?? ()
#40 0x286a3b25 in ?? ()
#41 0x00000003 in ?? ()
#42 0xbfbfe700 in ?? ()
```
...
```
#1649 0x102454ff in ?? ()
#1650 0x2024448d in ?? ()
#1651 0x5440f750 in ?? ()
#1652 0x00020000 in ?? ()
#1653 0x688e0375 in ?? ()
#1654 0x01a1b814 in ?? ()
#1655 0xcd500000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#1656 0x90feeb80 in ?? ()
#1657 0x102454ff in ?? ()
#1658 0x1424448d in ?? ()
#1659 0x5440f750 in ?? ()
#1660 0x00020000 in ?? ()
#1661 0x688e0375 in ?? ()
#1662 0x0158b814 in ?? ()
#1663 0xcd500000 in ?? ()
#1664 0x90feeb80 in ?? ()
#1665 0x102454ff in ?? ()
#1666 0x1424448d in ?? ()
#1667 0x1840f750 in ?? ()
#1668 0x00020000 in ?? ()
#1669 0x688e0375 in ?? ()
#1670 0x0067b844 in ?? ()
#1671 0xcd500000 in ?? ()
#1672 0x90feeb80 in ?? ()
#1673 0xbfbfecb0 in ?? ()
#1674 0x00000004 in ?? ()
#1675 0xbfbfecc4 in ?? ()
#1676 0x00000013 in ?? ()
Error accessing memory address 0xbfc00000: Bad address.
(gdb)
```
All addresses from #624 through #1648 are 0x00000000, if that helps.
I don't really *want* to recompile X with debugging symbols, because the
computer in question is a crummy old laptop with overheating issues, but I'm
considering it. I haven't found any similar bugs in bugzilla in my searches so
far; if I can glean any more info out of my system I'll post it back here.
Version: 6.9.0https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/4Screen garbled in some apps when using Xinerama with Sis and Matrox cards2018-08-10T20:43:11ZBugzilla Migration UserScreen garbled in some apps when using Xinerama with Sis and Matrox cards## Submitted by Krzysztof Lichota
Assigned to **Xorg Project Team**
**[Link to original bug (#6693)](https://bugs.freedesktop.org/show_bug.cgi?id=6693)**
## Description
I am using Xinerama with two cards: builtin Sis and Matrox on...## Submitted by Krzysztof Lichota
Assigned to **Xorg Project Team**
**[Link to original bug (#6693)](https://bugs.freedesktop.org/show_bug.cgi?id=6693)**
## Description
I am using Xinerama with two cards: builtin Sis and Matrox on PCI.
In some apps (notably Thunderbird, sometimes Acrobat Reader) on right screen
text is not printed and title bars are scrambled.
Right screen is Matrox card, left is Sis.
I will attach screenshots and Xorg logs.
Version: 6.9.0https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/5Virtual desktop max. size 4 million pixels2018-08-10T20:43:21ZBugzilla Migration UserVirtual desktop max. size 4 million pixels## Submitted by Kimmo Sundqvist
Assigned to **Xorg Project Team**
**[Link to original bug (#7033)](https://bugs.freedesktop.org/show_bug.cgi?id=7033)**
## Description
I have a display capable of 1280x1024. I'm working on a map pro...## Submitted by Kimmo Sundqvist
Assigned to **Xorg Project Team**
**[Link to original bug (#7033)](https://bugs.freedesktop.org/show_bug.cgi?id=7033)**
## Description
I have a display capable of 1280x1024. I'm working on a map project, and wanted
to have as big virtual screen as possible. So, I put "Virtual 2304 1728" into
the screen section of xorg.conf. My card is a Matrox G400 and this is an
average Pentium III class machine.
I've noticed I am unable to get bigger virtual screen than 2048 x 2048 = 4 194
304 pixels. Otherwise parts of the screen get overlaid (painted twice) and X
soon crashes. Is there any way around this? I have 32MB video memory, and that
should be enough for another 4 million pixels of virtual desktop real estate.
Version: 7.0.0https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/6Xv does not work after resuming from software suspend2018-08-10T20:43:23ZBugzilla Migration UserXv does not work after resuming from software suspend## Submitted by Michal Suchanek
Assigned to **Xorg Project Team**
**[Link to original bug (#7094)](https://bugs.freedesktop.org/show_bug.cgi?id=7094)**
## Description
The mplayer output xv (which is supposed to use the Xv extensio...## Submitted by Michal Suchanek
Assigned to **Xorg Project Team**
**[Link to original bug (#7094)](https://bugs.freedesktop.org/show_bug.cgi?id=7094)**
## Description
The mplayer output xv (which is supposed to use the Xv extension) does not work
when the system with a running X server is suspended and resumed using Linux
software suspend.
Only blue square is displayed instead of the video surface. I did not try
suspending running mplayer, only start mplayer after resume.
Before the system is suspended Xv works fine.
Tried with a mga G400 card.
Version: 6.8.2https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/7MGA 2064W hangs in dual-head setup2018-08-10T20:43:25ZBugzilla Migration UserMGA 2064W hangs in dual-head setup## Submitted by Enrico Scholz
Assigned to **Xorg Project Team**
**[Link to original bug (#7103)](https://bugs.freedesktop.org/show_bug.cgi?id=7103)**
## Description
When having a primary AGP graphic cards (in my case an ATI Radeon...## Submitted by Enrico Scholz
Assigned to **Xorg Project Team**
**[Link to original bug (#7103)](https://bugs.freedesktop.org/show_bug.cgi?id=7103)**
## Description
When having a primary AGP graphic cards (in my case an ATI Radeon
RV100 QY) and a PCI Matrox MGA 2064W, X will hang at startup.
This happens because the BIOS address can not be determined; the
interesting code is in mga_driver.c
| static Bool
| MGAPreInit(ScrnInfoPtr pScrn, int flags)
|
| if (pMga->device->BiosBase != 0) {
| /* XXX This isn't used */
| pMga->BiosAddress = pMga->device->BiosBase;
| pMga->BiosFrom = X_CONFIG;
| } else {
| /* details: rombase sdk pp 4-15 */
| if (pMga->PciInfo->biosBase != 0) {
| pMga->BiosAddress = pMga->PciInfo->biosBase & 0xffff0000;
| pMga->BiosFrom = X_PROBED;
| } else if (pMga->Primary) {
| pMga->BiosAddress = 0xc0000;
| pMga->BiosFrom = X_DEFAULT;
| }
| }
In my case, both pMga->device->BiosBase and pMga->PciInfo->biosBase
are NULL and pMga->Primary is false.
Therefore, 'pMga->BiosAddress == 0' will hold. Then, the startup will
hang somewhere in
| mga_read_and_process_bios( pScrn );
Skipping this operation (like in the '#if defined(__alpha__)'
conditional), will continue the startup process but:
* it will hang later somewhere in int10, or (when not loading the
int10 module),
* X will startup, but will assume wrong capabilities so that I have
only a 640x480 screen.
I fixed the issue by applying
|- } else if (pMga->Primary) {
|+ } else if (pMga->Primary || 1) {
to the code above and X runs without problems.
Environment:
Fedora Core 5, xorg-x11-drv-mga-1.2.1.3-1.2
| 00:0e.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] (rev 01) (prog-if 00 [VGA])
| 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
vanilla 2.6.16 kernel; mga-fb kernel driver *IS* activated
xorg-x11 from Fedora Core 4 (xorg-x11-6.8.2) worked without problems
on this hardware.
Version: 7.0 (2005.12)https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/issues/2FireMV 2400 card second M9 not initialized2019-11-29T15:22:09ZBugzilla Migration UserFireMV 2400 card second M9 not initialized## Submitted by Erwin Rol
Assigned to **xf86-video-ati maintainers**
**[Link to original bug (#7358)](https://bugs.freedesktop.org/show_bug.cgi?id=7358)**
## Description
The FireMV 2400 card is a PCI card with two Radeon M9 chips ...## Submitted by Erwin Rol
Assigned to **xf86-video-ati maintainers**
**[Link to original bug (#7358)](https://bugs.freedesktop.org/show_bug.cgi?id=7358)**
## Description
The FireMV 2400 card is a PCI card with two Radeon M9 chips connected via a PLX<br>
PCI-PCI bridge. The system BIOS only initializes the first M9 but the driver<br>
needs to initialize the second M9, this worked in Xorg 7.0 but doesn't work<br>
anymore in 7.1. The result is the second M9 is completely un initialized and<br>
will hard hang the system as soon as someone tries to access it (like moving the<br>
mouse from screen 2 to 3).<br>
<br>
The cause seems that Xorg 7.1 does a better job in detecting PCI-ROMs and finds<br>
the PCI-ROM of the second chip (that is only 2k in size and does not hold the<br>
BIOS, but probably just the chip settings), because it finds the ROM it does not<br>
check if it is a multi device card, and so never initializes the second M9. <br>
<br>
The diff shows a way to work around this problem on my (and only my) system, by<br>
checking for the PCI-ID (2:5.0) of the second M9 and skip the BIOS detection<br>
code and directly go to the multi device detection code. With this patch my card<br>
works correctly. Of course this is no real sollution , it jsut shows that the<br>
card does work, and where to look for a possible real solution. <br>
<br>
diff -ru xorg-server-1.1.0.orig/hw/xfree86/os-support/bus/Pci.c<br>
xorg-server-1.1.0.er/hw/xfree86/os-support/bus/Pci.c<br>
--- xorg-server-1.1.0.orig/hw/xfree86/os-support/bus/Pci.c 2006-05-19<br>
01:51:34.000000000 +0200<br>
+++ xorg-server-1.1.0.er/hw/xfree86/os-support/bus/Pci.c 2006-06-29<br>
00:25:52.000000000 +0200<br>
@@ -1305,16 +1305,21 @@<br>
PCITAG *pTag;<br>
int i;<br>
<br>
- /* fall back to the old code if the OS code fails */<br>
- if (pciOSHandleBIOS) {<br>
- n = pciOSHandleBIOS(Tag, basereg, buf, len);<br>
- if (n)<br>
- return n;<br>
- }<br>
+ /* MEGA DIRTY FOR ME ONLY TEST HACK */<br>
+<br>
+ if ( !((PCI_BUS_FROM_TAG(Tag) == 2) && (PCI_DEV_FROM_TAG(Tag) == 5) &&<br>
(PCI_FUNC_FROM_TAG(Tag) == 0))) {<br>
+ /* fall back to the old code if the OS code fails */<br>
+ if (pciOSHandleBIOS) {<br>
+ n = pciOSHandleBIOS(Tag, basereg, buf, len);<br>
+ if (n)<br>
+ return n;<br>
+ }<br>
<br>
- n = handlePciBIOS( Tag, basereg, buf, len );<br>
- if (n)<br>
- return n;<br>
+ n = handlePciBIOS( Tag, basereg, buf, len );<br>
+ if (n)<br>
+ return n;<br>
+<br>
+ }<br>
<br>
num = pciTestMultiDeviceCard(PCI_BUS_FROM_TAG(Tag),<br>
PCI_DEV_FROM_TAG(Tag),https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/8xorg 7.0 Screen corruption with mga module when composite is off2018-08-10T20:43:27ZBugzilla Migration Userxorg 7.0 Screen corruption with mga module when composite is off## Submitted by Huw Blackwell
Assigned to **Xorg Project Team**
**[Link to original bug (#7575)](https://bugs.freedesktop.org/show_bug.cgi?id=7575)**
## Description
Bug passed upstream from Gentoo Bugzilla (https://bugs.gentoo.org...## Submitted by Huw Blackwell
Assigned to **Xorg Project Team**
**[Link to original bug (#7575)](https://bugs.freedesktop.org/show_bug.cgi?id=7575)**
## Description
Bug passed upstream from Gentoo Bugzilla (https://bugs.gentoo.org Bug #140757).
Xorg 7.0 server causes screen corruption on a Matrox G200 8Mb card (HP Brio
BA600, Pentium III 750, 512Mb) when Xserver
is running. X server starts successfully from the command line, but wallpaper
and text is so corrupted that it is unreadable (I hope to submit some photos of
this). Shutting down the X server and returning to the command line (vesa
fbuffer) results in continuing corruption of the text on screen and the command
line. This occurs using xfce4 (latest stable version). This corruption can be
rectified by starting X and using twm. This appears to resolve most of the
corruption issues, though any programs run in it can suffer the same issue.
Howevere, 9/10 times when the x server is shut down under twm the command line
returns to it's previous uncorrupted state.
When booted using recent kernels (2.6.16) the command line cursor does not
appear at the command line, but further up the screen. When typing this
corrupts the line it is on whilst the text appears at the command line. This
can be resolved by using ctrl-alt to switch to a nother tyermianl causing the
cursor to return to the command line. Switching back to the orignal terminal
results in correct cursor position, and no further text corruption. This only
effects the 2.6.16 series of kernels. Changing kernels (2.6.15-r1) resolves
this but has no effect on the earlier problem.
This is always reproducible. It is solved by enabling the Xfce4 compositor,
though this affects flash running in firefox, which requires a line of code to
fix (see gentoo-wiki, article Xorg and Transparency).
Version: 7.0.0https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/9mga ddc support was lost between XFree86 Version 4.0.1 and 4.0.22018-08-10T20:43:35ZBugzilla Migration Usermga ddc support was lost between XFree86 Version 4.0.1 and 4.0.2## Submitted by Olaf Hering
Assigned to **Xorg Project Team**
**[Link to original bug (#8354)](https://bugs.freedesktop.org/show_bug.cgi?id=8354)**
## Description
the mga driver in SuSE Linux 7.0 does DDC, but the one in SuSE Linu...## Submitted by Olaf Hering
Assigned to **Xorg Project Team**
**[Link to original bug (#8354)](https://bugs.freedesktop.org/show_bug.cgi?id=8354)**
## Description
the mga driver in SuSE Linux 7.0 does DDC, but the one in SuSE Linux 7.1 does
not do it anymore.
This functionality should be restored.
Version: 7.1 (2006.05)https://gitlab.freedesktop.org/xorg/driver/xf86-video-fbdev/-/issues/1fbdev + offb 8bit colormap problems2018-08-10T20:41:29ZBugzilla Migration Userfbdev + offb 8bit colormap problems## Submitted by Peter Samuelson
Assigned to **Xorg Project Team**
**[Link to original bug (#9564)](https://bugs.freedesktop.org/show_bug.cgi?id=9564)**
## Description
fbdev 0.3.1 with Linux offb (kernel 2.6.17), 1280x1024_8bit, ha...## Submitted by Peter Samuelson
Assigned to **Xorg Project Team**
**[Link to original bug (#9564)](https://bugs.freedesktop.org/show_bug.cgi?id=9564)**
## Description
fbdev 0.3.1 with Linux offb (kernel 2.6.17), 1280x1024_8bit, hardware is IBM
GXT2000P on RS/6000 (PowerPC). Most colors show up as black. White shows up as
blue (perhaps #0000FF). I can also get something that looks like #FF80FF or so
- this is when xterm is trying to display bold green.
The Linux text console (also using offb) works fine, with the full range of 16
ANSI colors.
I'd be happy to provide logfiles and test patches.
Version: 7.1 (2006.05)https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/-/issues/6kbd driver should not change keyboard repeat settings in VT2018-08-10T20:55:08ZBugzilla Migration Userkbd driver should not change keyboard repeat settings in VT## Submitted by Brice Goglin `@bgoglin`
Assigned to **Xorg Project Team**
**[Link to original bug (#10828)](https://bugs.freedesktop.org/show_bug.cgi?id=10828)**
## Description
Bug reported on the Debian BTS by Andrew T.Young 4 ye...## Submitted by Brice Goglin `@bgoglin`
Assigned to **Xorg Project Team**
**[Link to original bug (#10828)](https://bugs.freedesktop.org/show_bug.cgi?id=10828)**
## Description
Bug reported on the Debian BTS by Andrew T.Young 4 years ago, still applies.
"I've noticed for some time now that after I've used X and then switch back to a console with `<ctrl>``<alt>``<Fn>`, the keyboard rate and delay have been reset to Debian's default values (long delay, fast rep rate) instead of the IBM defaults that I prefer, and which I normally set up by using "kbdrate" from a console with no arguments.
In my .xsession file, I *do* call `xset r rate 250 11` to re-establish my preferred rate and delay. This makes the keyboard behave properly in an xterm or rxvt window; but it does not prevent X from messing up the consoles.
It seems to me that even if X has to play with the keyboard for its own internal reasons -- something that does not seem logically necessary, but suppose it is -- then at least the use of the xset command ought to leave things in the intended state when I go back to a console."
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181423 for details.
Assigning to Daniel as discussed on IRC a couple minutes ago.
Version: 7.2 (2007.02)