xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2018-08-10T20:30:15Zhttps://gitlab.freedesktop.org/xorg/app/xinit/-/issues/2xinit sends SIGKILL to server too aggressively2018-08-10T20:30:15ZBugzilla Migration Userxinit sends SIGKILL to server too aggressively## Submitted by Andrew Moise
Assigned to **Xorg Project Team**
**[Link to original bug (#12393)](https://bugs.freedesktop.org/show_bug.cgi?id=12393)**
## Description
With several recent versions of the intel driver, I've had occas...## Submitted by Andrew Moise
Assigned to **Xorg Project Team**
**[Link to original bug (#12393)](https://bugs.freedesktop.org/show_bug.cgi?id=12393)**
## Description
With several recent versions of the intel driver, I've had occasional black screens while exiting X. Instead of going back to my VGA-mode console, the screen goes into DPMS mode and numlock on the keyboard stops working. It seems to happen more frequently under load, but that could be my imagination.
I've seen this problem in the following versions of the intel driver:
* Debian-packaged 2.0.0-5
* Debian-packaged 2.1.1-1
* git checkout from 2007-08-31 (7fd9a98178cdebda4213796fdc452a8a265a1197)
I'll attach a log and a config.
Cheers!
### Blocking
* [Bug 13027](https://bugs.freedesktop.org/show_bug.cgi?id=13027)
* [Bug 13493](https://bugs.freedesktop.org/show_bug.cgi?id=13493)https://gitlab.freedesktop.org/xorg/xserver/-/issues/655Binding keys with keycodes > 127 to XKB modifiers doesn't work2019-03-10T18:55:19ZBugzilla Migration UserBinding keys with keycodes > 127 to XKB modifiers doesn't work## Submitted by Marius Gedminas
Assigned to **Xorg Project Team**
**[Link to original bug (#12401)](https://bugs.freedesktop.org/show_bug.cgi?id=12401)**
## Description
My Thinkpad T61 has a few keys that act strangely in X: Menu,...## Submitted by Marius Gedminas
Assigned to **Xorg Project Team**
**[Link to original bug (#12401)](https://bugs.freedesktop.org/show_bug.cgi?id=12401)**
## Description
My Thinkpad T61 has a few keys that act strangely in X: Menu, Workspace
Prev, Workspace Next. By "acting strangely" I mean:
1. xset -r disables autorepeat for all the keys on the keyboard except
for these three (and Fn).
2. It appears to be impossible to map these keys to modifiers (neither
with xmodmap, nor with custom xkb symbols files)
The Menu key sends keycode 227 (instead of the usual 117 I get from the
Menu key on a USB keyboard). I'm trying to map it to a ISO_Level3_Shift
with
xmodmap -e 'keycode 227 = ISO_Level3_Shift' -e 'add mod5 = ISO_Level3_Shift'
and xev shows me the keysym correctly, but the state remains 0x0. Why?
I had the same problem mapping keycode 234 to Alt, and I went as far as
to compile a custom XKB description so that xkbcomp :0 - showed me
identical configurations for it and the real Alt key.
I can map these extra keys to, e.g., Multi_key, but not to any of the modifiers.
The Menu key on a USB keyboard, the one that sends keycode 117, is also mapped
to ISO_Level3_Shift. It autorepeats, but despite that the state bit flips to
0x80 while I hold it down. xmodmap shows both 0xe3 (227) and 0x75 (117) among
the keys mapped to mod5.
The only difference I can think of is that one keycode is < 128, while
the other one needs full 8 bits. Just a blind guess, but could the XKB
code be using signed chars somewhere and sign-extending them to ints?
This is with xserver 1.3.0 (Ubuntu's xorg-server 2:1.3.0.0.dfsg-12ubuntu3).
I've had the problem with older versions as well.https://gitlab.freedesktop.org/xorg/xserver/-/issues/356xmodmap in ~/.xinitrc not working anymore2018-12-13T22:18:18ZBugzilla Migration Userxmodmap in ~/.xinitrc not working anymore## Submitted by Konstantin Kletschke
Assigned to **Xorg Project Team**
**[Link to original bug (#12523)](https://bugs.freedesktop.org/show_bug.cgi?id=12523)**
## Description
On my gentoo System xorg was updated to 7.4 (xorg-server...## Submitted by Konstantin Kletschke
Assigned to **Xorg Project Team**
**[Link to original bug (#12523)](https://bugs.freedesktop.org/show_bug.cgi?id=12523)**
## Description
On my gentoo System xorg was updated to 7.4 (xorg-server-1.4) and now I need to call "xmodmap ~/.Xmodmap" from a xterm after starting, then it works. Not the .xinitrc call anymore :-/
### Blocking
* [Bug 16364](https://bugs.freedesktop.org/show_bug.cgi?id=16364)https://gitlab.freedesktop.org/xorg/xserver/-/issues/357xorg-server should create symlink and directory for compiled keyboard layouts2018-12-13T22:18:27ZBugzilla Migration Userxorg-server should create symlink and directory for compiled keyboard layouts## Submitted by Samuel Verstraete
Assigned to **Xorg Project Team**
**[Link to original bug (#12639)](https://bugs.freedesktop.org/show_bug.cgi?id=12639)**
## Description
As Daniel Stone himself indicates in this bug:
https://bugs...## Submitted by Samuel Verstraete
Assigned to **Xorg Project Team**
**[Link to original bug (#12639)](https://bugs.freedesktop.org/show_bug.cgi?id=12639)**
## Description
As Daniel Stone himself indicates in this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=9246
Version: 7.3 (2007.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/358xkb resets configuration loaded with xkbcomp2018-12-13T22:18:32ZBugzilla Migration Userxkb resets configuration loaded with xkbcomp## Submitted by Konstantin Sobolev
Assigned to **Xorg Project Team**
**[Link to original bug (#13011)](https://bugs.freedesktop.org/show_bug.cgi?id=13011)**
## Description
I have a Microsoft Natural Ergonomic Keyboard 4000. My 2.6...## Submitted by Konstantin Sobolev
Assigned to **Xorg Project Team**
**[Link to original bug (#13011)](https://bugs.freedesktop.org/show_bug.cgi?id=13011)**
## Description
I have a Microsoft Natural Ergonomic Keyboard 4000. My 2.6.23 kernel is patched with liyu's patch mentioned here:
http://ubuntuforums.org/showthread.php?t=229559&page=11
I'm loading my custom xkb settins using "xkbcomp -a -R/home/kos/.xkb xkb $DISPLAY" command after server startup. Configuration files are attached, but they basically follow this howto: http://gentoo-wiki.com/HOWTO_Microsoft_Natural_Ergonomic_Keyboard_4000
It used to work perfectly on xorg-server-1.3, but I've installed 1.4 on my new box and have a couple of problems with it.
First, 'My Favorites' button crashes X:
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6a) [0x476f52]
1: /lib/libc.so.6 [0x2b0ada7ad470]
2: /lib/libc.so.6 [0x2b0ada7f2d1b]
3: /lib/libc.so.6(memmove+0x73) [0x2b0ada7f1c23]
4: /usr/bin/X(SetKeySymsMap+0x1b6) [0x446394]
5: /usr/bin/X(SwitchCoreKeyboard+0xe3) [0x45ba70]
6: /usr/bin/X(mieqProcessInputEvents+0x167) [0x4cfd80]
7: /usr/bin/X(ProcessInputEvents+0x1c) [0x477661]
8: /usr/bin/X(Dispatch+0x7d) [0x44d1d7]
9: /usr/bin/X(main+0x47f) [0x436f75]
10: /lib/libc.so.6(__libc_start_main+0xf4) [0x2b0ada79ab74]
11: /usr/bin/X(FontFileCompleteXLFD+0x249) [0x436339]
May be it has something to do with https://bugs.freedesktop.org/show_bug.cgi?id=9180
Next, updated XKB configuration works for some time (for instance, Esc and Win keys are swapped as I like it), but is reset to the default one defined in xorg.conf as soon as I press any additional key. It happens silently, there are no messages in Xorg.0.log or dmesg or anywhere else.
My keyboard is configured in xorg.conf as two devices (see gentoo's howto above for details), main keys use 'kbd' driver, and aux keys use 'evdev' driver. It looks like XKB configuration is reset as soon as evdev sends any event, i.e. any aux key is pressed.
Once again, the same configuration works in xorg-server-1.3 flawlessly.
System info: EM64T, (64-bit) Gentoo, 2.6.23 gentoo sources with liyu's patch. System was compiled from scratch, it wasn't an upgrade from 7.1 or something else.
Version: 7.3 (2007.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/120in Xephyr, using Render to composite a transformed, redirected window has biz...2018-12-13T18:27:15ZBugzilla Migration Userin Xephyr, using Render to composite a transformed, redirected window has bizarre coordinate problems## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Eric Anholt `@anholt`**
**[Link to original bug (#13116)](https://bugs.freedesktop.org/show_bug.cgi?id=13116)**
## Description
I'm attaching a test program (requires gtk >=2....## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Eric Anholt `@anholt`**
**[Link to original bug (#13116)](https://bugs.freedesktop.org/show_bug.cgi?id=13116)**
## Description
I'm attaching a test program (requires gtk >=2.12, cairo, and python bindings to both). The test program creates two toplevel windows, sets one to manual redirection, and then just repeatedly draws a gradient image into the
redirected window, and composites the image of the redirected window into
the other 'display' window, using Render (via cairo -- I've verified that the
expected Render operations are occurring with xtrace). The display window also has a little white dot placed at where the upper-left corner of the composited image *should* land, given the transform matrix in use.
To test, run Xephyr, start a window manager, then start the test program and move the two windows around on the screen. Moving the display window has no effect. Moving the redirected window against the root window causes its image inside the display window to veer wildly -- each time the real window goes to the left, its image goes to the right, and so on. The only time it appears at the correct location is if the redirected window is placed at position (0, 0) against the root. (I'll also attach a little ogg video to show this.)
The amount of the offset seems to vary inversely with the scale factor applied. With a scale factor of 1, the display is correct. As the scale factor goes to 1, it looks like the transformed image moves by 1 pixel for every 1 pixel the redirected window moves by. For intermediate scale factors, the transformed image moves by intermediate amounts as the redirected window is moved. See attached screenshot.
I am deeply suspicious of the handling of redirected windows' ->screen_x/->screen_y offsets. It is like one piece of code is expected to leave the offsets in, and then they are corrected for later, but the first piece of code is multiplying them by the scale factor and the latter code is assuming a scale factor of 1 when it applies its correction.... or something.
This is with X.org 1.4.0 (Debian sid, xorg-server 2:1.4-3), on x86-64.
Version: 7.3 (2007.09)Emma Anholtemma@anholt.netEmma Anholtemma@anholt.nethttps://gitlab.freedesktop.org/xorg/xserver/-/issues/129in Xephyr with -fakexa, using Render to composite a transformed, redirected w...2018-12-13T18:27:32ZBugzilla Migration Userin Xephyr with -fakexa, using Render to composite a transformed, redirected window has *really* bizarre coordinate problems## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Matthew Allum**
**[Link to original bug (#13117)](https://bugs.freedesktop.org/show_bug.cgi?id=13117)**
## Description
This is basically a repeat of #13116, except for runnin...## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Matthew Allum**
**[Link to original bug (#13117)](https://bugs.freedesktop.org/show_bug.cgi?id=13117)**
## Description
This is basically a repeat of #13116, except for running Xephyr in its -fakexa rendering mode, so see that bug's intial filing for details. The same test program generates even stranger results -- the same thing happens when the redirected window is moved against the root (its composited image moves around inside its coordinate space), but with -fakexa, moving the display window around against the root *also* causes its contents to move in strange ways. The whole coordinate system appears to be translated around -- both the composited image and the white box that I draw directly to show the origin of the transformed coordinate system move around together. I've attached a movie of this weirdness.
If I set the scaling factor to 1 and move the redirected window around, then its display does not move. If I move the display window around instead, then something odd happens as well -- the white origin box that I draw moves around just as in the above movie, but now the composited image of the redirected window remains fixed, at the correct location (!).
Version: 7.3 (2007.09)https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/7GLX is missing Render sub-requests2019-02-17T18:06:53ZBugzilla Migration UserGLX is missing Render sub-requests## Submitted by Peter Harris `@peterh`
Assigned to **Josh Triplett**
**[Link to original bug (#13133)](https://bugs.freedesktop.org/show_bug.cgi?id=13133)**
## Description
GLX is missing Render sub-requests. This is critical for x...## Submitted by Peter Harris `@peterh`
Assigned to **Josh Triplett**
**[Link to original bug (#13133)](https://bugs.freedesktop.org/show_bug.cgi?id=13133)**
## Description
GLX is missing Render sub-requests. This is critical for xcb-server, and would be nice for a hypothetical xscope or xmond based on XCB/proto.
At the very least, the TODO file should be updated:
```
diff --git a/TODO b/TODO
index add693c..dfd6a38 100644
--- a/TODO
+++ b/TODO
@@ -12,7 +12,7 @@ X DAMAGE
DOUBLE-BUFFER
X DPMS
Extended-Visual-Information
-X GLX
+I GLX
LBX
X MIT-SCREEN-SAVER
X MIT-SHM
```https://gitlab.freedesktop.org/xorg/app/xrandr/-/issues/1xrandr with multiple --output works unreliable2022-04-06T01:48:50ZBugzilla Migration Userxrandr with multiple --output works unreliable## Submitted by Stefan Becker
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#13457)](https://bugs.freedesktop.org/show_bug.cgi?id=13457)**
## Description
Testing output switching with radeonhd and the latest xra...## Submitted by Stefan Becker
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#13457)](https://bugs.freedesktop.org/show_bug.cgi?id=13457)**
## Description
Testing output switching with radeonhd and the latest xrandr git
commit 4bc84c331f4f0f0658ad1f6c0107e3e6af2a7911
revealed that using multiple --output on the command line works unreliable. E.g.
xrandr --output DVI-D_1 --mode 1280x720 --output PANEL --off
does not always switch to the desired state but
xrandr --output DVI-D_1 --mode 1280x720
xrandr --output PANEL --off
always works correctly.
Version: gitKeith PackardKeith Packardhttps://gitlab.freedesktop.org/xorg/test/xts/-/issues/14[g965] Xtest case "XCloseDisplay 28" hangs2019-10-08T23:04:08ZBugzilla Migration User[g965] Xtest case "XCloseDisplay 28" hangs## Submitted by Pi, Fengming
Assigned to **Xorg Project Team**
**[Link to original bug (#13766)](https://bugs.freedesktop.org/show_bug.cgi?id=13766)**
## Description
System Environment:
--------------------------
--Platform: g965...## Submitted by Pi, Fengming
Assigned to **Xorg Project Team**
**[Link to original bug (#13766)](https://bugs.freedesktop.org/show_bug.cgi?id=13766)**
## Description
System Environment:
--------------------------
--Platform: g965
--Architecture(32-bit): ia32
--2D driver: git commit:d9df93578b74785c08ba860b4c9aa23b0c89c91c
--3D driver: Mesa master commit:e54329233522591bbe8aad8a3fd6bcdc1e430f03
--DRM: git commit:2db6400396ea5c8a5ce54fe9e211b9d01a11d506
--Xserver: git commit:7ef7727b800fa4715b80a82850d65b88fde5fe6c
--Kernel: 2.6.23
Bug Description:
when Xtest run to case "XCloseDisplay 28" on g965(32bit) with git source
code. It will stop at there until you kill the process by hand.
Reproduce step:
1 X &
2 xterm &
3 tcc -e xts5 XCloseDisplay
### Depends on
* [Bug 14418](https://bugs.freedesktop.org/show_bug.cgi?id=14418)https://gitlab.freedesktop.org/xorg/xserver/-/issues/249RFE: Temporary configuration changes for RANDR2018-12-13T18:34:54ZBugzilla Migration UserRFE: Temporary configuration changes for RANDR## Submitted by Artem S. Tashkinov
Assigned to **Xorg Project Team**
**[Link to original bug (#14255)](https://bugs.freedesktop.org/show_bug.cgi?id=14255)**
## Description
Applications like games change desktop resolution (graphic...## Submitted by Artem S. Tashkinov
Assigned to **Xorg Project Team**
**[Link to original bug (#14255)](https://bugs.freedesktop.org/show_bug.cgi?id=14255)**
## Description
Applications like games change desktop resolution (graphics mode) for their needs. Unfortunately when such applications crash then X.org server doesn't revert the resolution back to its initial mode.
It's a bug.
Please, consult with thus Wine bug for details: http://bugs.winehq.org/show_bug.cgi?id=10115
Version: git
### See also
* https://bugs.kde.org/show_bug.cgi?id=152155
* http://bugs.winehq.org/show_bug.cgi?id=3230
* http://bugs.winehq.org/show_bug.cgi?id=10115
* http://bugs.winehq.org/show_bug.cgi?id=10841
* http://bugs.winehq.org/show_bug.cgi?id=12386
* http://bugs.winehq.org/show_bug.cgi?id=16219
* http://bugs.winehq.org/show_bug.cgi?id=16396
* http://bugs.winehq.org/show_bug.cgi?id=20833
* http://bugs.winehq.org/show_bug.cgi?id=22700
* http://bugs.winehq.org/show_bug.cgi?id=25296
* http://bugs.winehq.org/show_bug.cgi?id=28637
* http://bugs.winehq.org/show_bug.cgi?id=29826https://gitlab.freedesktop.org/xorg/xserver/-/issues/359Xserver ignores Option PreferredMode for the second output when there's a Pre...2018-12-13T22:18:38ZBugzilla Migration UserXserver ignores Option PreferredMode for the second output when there's a Preferred for the first output## Submitted by Brice Goglin `@bgoglin`
Assigned to **Xorg Project Team**
**[Link to original bug (#14267)](https://bugs.freedesktop.org/show_bug.cgi?id=14267)**
## Description
Bug reported by Anders Hammarquist on the Debian BTS....## Submitted by Brice Goglin `@bgoglin`
Assigned to **Xorg Project Team**
**[Link to original bug (#14267)](https://bugs.freedesktop.org/show_bug.cgi?id=14267)**
## Description
Bug reported by Anders Hammarquist on the Debian BTS. He says:
"I have dual monitor setup, one widescreen LCD and an older CRT. Trying to get different default modes on the two screens appears impossible. The CRT does apparently not specify a preferred mode in its EDID, and without any setting in xorg.conf it runs at the same 1680x1050 resolution as the LCD.
Trying to add an Option PreferredMode to its Monitor section in xorg.conf resulted in the LCD also running at (the specified) 1280x1024. Adding an Option PreferredMode to the LCD Monitor section had no effect (it still ran at 1280x1024).
xrandr however, shows the + in the proper place for both monitors, so at least something is picking up the PreferredMode, it's just not properly applied when the initial mode is selected."
His config and log are available at
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=462562
The xrandr output (after changing the modes) is at
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;bug=462562
This could be a followup to bug#10625 which is fixed in master but it was only about configs with a single PreferredMode option.
Anders is using the latest Debian snapshot of Xserver 1.4.1 which includes the fix for #10625 (only applied to master).
Version: 7.3 (2007.09)https://gitlab.freedesktop.org/xorg/test/xts/-/issues/11Xlib15 tests fail against newer libX112019-10-08T23:00:04ZBugzilla Migration UserXlib15 tests fail against newer libX11## Submitted by Stew Benedict
Assigned to **Stuart Anderson `@anderson`**
**[Link to original bug (#14291)](https://bugs.freedesktop.org/show_bug.cgi?id=14291)**
## Description
Due to the changes introduced in libX11 here:
http:/...## Submitted by Stew Benedict
Assigned to **Stuart Anderson `@anderson`**
**[Link to original bug (#14291)](https://bugs.freedesktop.org/show_bug.cgi?id=14291)**
## Description
Due to the changes introduced in libX11 here:
http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=commit;h=0284b144340a455a4b5b5011d81ac5a610372291
Some of the Xlib15 tests now fail, returning '0' instead of the expected XSizeHints values:
/tset/Xlib15/gtwmnrmlhn/Test 1 FAIL
/tset/Xlib15/gtwmszhnts/Test 1 FAIL
/tset/Xlib15/stwmnrmlhn/Test 1 FAIL
/tset/Xlib15/stwmprprts/Test 4 FAIL
/tset/Xlib15/stwmszhnts/Test 1 FAIL
This is also being tracked in:
http://bugs.linuxbase.org/show_bug.cgi?id=1906Stuart AndersonStuart Andersonhttps://gitlab.freedesktop.org/xorg/app/xkbcomp/-/issues/23xkbcomp needs :all syntax for rules2023-03-27T14:45:00ZBugzilla Migration Userxkbcomp needs :all syntax for rules## Submitted by Sergey V. Udaltsov
Assigned to **Xorg Project Team**
**[Link to original bug (#14372)](https://bugs.freedesktop.org/show_bug.cgi?id=14372)**
## Description
As it was discussed on IRC, the following functionality is...## Submitted by Sergey V. Udaltsov
Assigned to **Xorg Project Team**
**[Link to original bug (#14372)](https://bugs.freedesktop.org/show_bug.cgi?id=14372)**
## Description
As it was discussed on IRC, the following functionality is needed in xkbcomp
If some XKB option is using some symbols in group 1, they should be propagated to all groups present in the configuration. Something like
! option = symbols
og:abc = symfile(v):all
// equal to og:abc = symfile(v):1 + symfile(v):2 + ... till the last group
### Blocking
* [Bug 14074](https://bugs.freedesktop.org/show_bug.cgi?id=14074)https://gitlab.freedesktop.org/xorg/xserver/-/issues/360EDID parser doesn't pick a preferred mode if one isn't marked2019-05-10T17:40:00ZBugzilla Migration UserEDID parser doesn't pick a preferred mode if one isn't marked## Submitted by Benjamin Otte `@company`
Assigned to **xf86-video-ati maintainers**
**[Link to original bug (#14383)](https://bugs.freedesktop.org/show_bug.cgi?id=14383)**
## Description
So the Ubuntu people said "please file this...## Submitted by Benjamin Otte `@company`
Assigned to **xf86-video-ati maintainers**
**[Link to original bug (#14383)](https://bugs.freedesktop.org/show_bug.cgi?id=14383)**
## Description
So the Ubuntu people said "please file this upstream", so here it goes. See
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/147846
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/189198
for further details, including various X logs.
The short summary is:
I have a R100 and it comes up in 1600x1024, which doesn't work properly. In fact, 1600x1024 and 1440x900 are the only non-working resolutions. Everything else from 1920x1200 to 640x350 works properly.
I'm running without xorg.conf, the Xorg log is at http://launchpadlibrarian.net/11769885/Xorg.0.log
Version: 7.3 (2007.09)https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/issues/5TV-out on Cyberblade/i1 (Epia 800): Only black screen2018-08-10T20:48:20ZBugzilla Migration UserTV-out on Cyberblade/i1 (Epia 800): Only black screen## Submitted by Jacob Barsøe Kjærgaard
Assigned to **Xorg Project Team**
**[Link to original bug (#14555)](https://bugs.freedesktop.org/show_bug.cgi?id=14555)**
## Description
Hi,
I have a trident cyberblade/i1 rev6a. However, th...## Submitted by Jacob Barsøe Kjærgaard
Assigned to **Xorg Project Team**
**[Link to original bug (#14555)](https://bugs.freedesktop.org/show_bug.cgi?id=14555)**
## Description
Hi,
I have a trident cyberblade/i1 rev6a. However, the tv-out does not work.
It does not work in either NTSC or PAL mode.I use the VT1621 chip.
If I use the chrontel chip setting in my xorg.conf I manage to get a picture, but the picture starts at a different pixel every time I restart X.
Using the VT1621 chip (which I guess is supposed to be the right choice for my chipset) the TV switches to black screen. It does switch though, but I cannot get back from the black screen. X is running perfectly in the background.
I have had tv-out working for a long time, but when migrating from xfree86 to xorg problems occured; first X started in black/white, however that could be circumvented by calling mplayer which on playback made the screen turn into colors, but later on, after I updated (gentoo update that is) in April last year the tv-out has gone all black.
I really hope you can help me out here - I don't want to transfer my HTPC into a windows machine:)
Regards,
Jacob
xorg version 7.3, xorg-server 1.4.0.90-r3 (gentoo).
trident-driver version 1.2.3
xorg.conf:
Section "Device"
Identifier "trident driver"
Driver "trident"
# Option "TVChipSet" "CH7005"
Option "TVChipSet" "VT1621"
# Option "TVSignal" "1"
Option "TVSignal" "0"
EndSection
xorg.log output: (grepped with TRIDENT)
(II) TRIDENT: driver for Trident chipsets: tvga9000, tvga9000i, tvga8900c,
(**) TRIDENT(0): Depth 16, (--) framebuffer bpp 16
(II) TRIDENT(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(==) TRIDENT(0): RGB weight 565
(==) TRIDENT(0): Default visual is TrueColor
(==) TRIDENT(0): Using gamma correction (1.0, 1.0, 1.0)
(**) TRIDENT(0): Option "TVChipset" "VT1621"
(**) TRIDENT(0): Option "TVSignal" "0"
(==) TRIDENT(0): Using XAA for acceleration
(**) TRIDENT(0): Using VIA VT1621 TV chip
(==) TRIDENT(0): Linear framebuffer at 0xD9800000
(--) TRIDENT(0): IO registers at 0xDA000000
(II) TRIDENT(0): initializing int10
(II) TRIDENT(0): Primary V_BIOS segment is: 0xc000
(II) TRIDENT(0): VESA BIOS detected
(II) TRIDENT(0): VESA VBE Version 2.0
(II) TRIDENT(0): VESA VBE Total Mem: 8192 kB
(II) TRIDENT(0): VESA VBE OEM: Copyright 1998 TRIDENT MICROSYSTEMS INC.
(II) TRIDENT(0): VESA VBE OEM Software Rev: 0.0
(II) TRIDENT(0): VESA VBE OEM Vendor:
(II) TRIDENT(0): VESA VBE OEM Product:
(II) TRIDENT(0): VESA VBE OEM Product Rev:
(II) TRIDENT(0): VESA VBE DDC supported
(II) TRIDENT(0): VESA VBE DDC Level 1 + 2
(II) TRIDENT(0): VESA VBE DDC transfer in appr. 1 sec.
(II) TRIDENT(0): VESA VBE DDC read failed
(--) TRIDENT(0): Revision is 106
(--) TRIDENT(0): Found CyberBlade/i1 chip
(--) TRIDENT(0): RAM type is SDRAM
(--) TRIDENT(0): Using SW cursor
(--) TRIDENT(0): VideoRAM: 8192 kByte
(--) TRIDENT(0): TFT Panel 800x600 found
(--) TRIDENT(0): Memory Clock is 57.27 MHz
(==) TRIDENT(0): Min pixel clock is 12 MHz
(--) TRIDENT(0): Max pixel clock is 230 MHz
(II) TRIDENT(0): My Monitor: Using hsync range of 31.50-35.10 kHz
(II) TRIDENT(0): My Monitor: Using vrefresh range of 50.00-70.00 Hz
(II) TRIDENT(0): Clock range: 12.00 to 230.00 MHz
(II) TRIDENT(0): Not using default mode "640x350" (hsync out of range)
(II) TRIDENT(0): Not using default mode "320x175" (bad mode ...
snipped all those "not using default mode"
(--) TRIDENT(0): Virtual size is 800x600 (pitch 800)
(**) TRIDENT(0): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz
(II) TRIDENT(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 6
25 +hsync +vsync (35.2 kHz)
(**) TRIDENT(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 59.9 Hz
(II) TRIDENT(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 52
5 -hsync -vsync (31.5 kHz)
(==) TRIDENT(0): DPI set to (75, 75)
(II) TRIDENT(0): Initializing int10
(II) TRIDENT(0): Primary V_BIOS segment is: 0xc000
(II) TRIDENT(0): Overriding Horizontal timings.
(II) TRIDENT(0): Shadow off
(II) TRIDENT(0): H-timing shadow registers: 0x7f 0x00 0x69 0x7f
(II) TRIDENT(0): H-timing registers: 0x7b 0x63 0x63 0x80 0x67 0x10
(II) TRIDENT(0): V-timing shadow registers: 0x72 0xf0 0x59 0x0d 0x00 (0
x08)
(II) TRIDENT(0): V-timing registers: 0x6f 0xf0 0x59 0x2b 0x57 0x00 0x00
(II) TRIDENT(0): Setting BIOS Mode: 77 for: 800x600
(II) TRIDENT(0): Found Clock 36.00 n=163 m=15 k=2
(II) TRIDENT(0): Using 1447 scanlines of offscreen memory for area's
(II) TRIDENT(0): Using 5113408 bytes of offscreen memory for linear (offset=0x31f
9c0)
(II) TRIDENT(0): Using XFree86 Acceleration Architecture (XAA)
(==) TRIDENT(0): Backing store disabled
(II) TRIDENT(0): Trident Video Flags: VID_ZOOM_INV VID_ZOOM_MINI
Version: 7.3 (2007.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/361DamageSubtract is misdesigned, making DeltaRectangles mode unusable2019-05-10T18:38:15ZBugzilla Migration UserDamageSubtract is misdesigned, making DeltaRectangles mode unusable## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#14648)](https://bugs.freedesktop.org/show_bug.cgi?id=14648)**
## Description
damageproto.txt, when describing the DamageSu...## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#14648)](https://bugs.freedesktop.org/show_bug.cgi?id=14648)**
## Description
damageproto.txt, when describing the DamageSubtract request, states:
DamageSubtract
[...]
Synchronously modifies the regions in the following manner:
(A) If repair is None:
1) parts = damage
2) damage = `<empty>`
(B) Otherwise:
1) parts = damage INTERSECT repair
2) damage = damage - parts
3) Generate DamageNotify for remaining damage areas
(Letters added for ease of reference.) My issue is with point B.3.
In my application[1], I request damage mode DamageReportDeltaRectangles. I accumulate these damage notifications in a GdkRegion in my client, and from time to time a separate socket becomes writeable and I pick a rectangle from my Region, subtract it from the server damage region (to indicate that I would like to re-enable damage notification for that rectangle), and send the image of that rectangle down my socket. This all works nicely, except for B.3: every time I re-enable damage notifications on one rectangle with DamageSubtract, I get a giant flurry of pointless notifications for damage rectangles I have already recorded. Then I handle the next rectangle, and get another flurry... ultimately this makes a simple redraw operation O(n^2), and in real-world cases can cause my program to thrash for several minutes to deliver a single screen update.
The only way DeltaRectangles mode makes any sense to use at all is if one has this basic strategy of accumulating damage locally and issuing DamageSubtract when a piece of it is handled. Given such a strategy, re-issuing notifications is utterly pointless.
A simple but inefficient workaround is to use mode RawRectangles; for this mode the current X server violates the spec and makes DamageSubtract a complete no-op.
I am not entirely certain what the right fix here is:
Option 1: Stop re-issuing notifications, as per B.3, for damage level DeltaRectangles.
Option 2: Just kill B.3 entirely -- never re-issue damage notifications.
Either of these will solve my problem, obviously; the question is which is cleaner, and in particular whether there is any use case where the re-issued damage notifications are valuable. They seem to be in the spec entirely for the benefit of mode NonEmpty, but I can't figure out how one could use them without race conditions. If one is using notification mode NonEmpty, one should be setting repair=None anyway, and avoiding this whole problem... Maybe Keith or Eric, whose names are on the spec, can explain the rationale?
Also, looking through all the different uses of DamageSubtract in google codesearch, it appears that they fall into two classes:
-- traditional cm's, which use NonEmpty and set repair=None, so they take branch A and B.3 is irrelevant.
-- apps that want to keep track of what's on the screen (like xpra, and byzanz, and vino), which use DeltaRectangles and are bitten by this bug.
So just removing damage re-notifications entirely seems like a viable course of action.
Anyway, what I'd request:
-- damage re-issuing be fixed for, at least, DeltaRectangles mode for 7.4
-- the Damage protocol version get bumped to 1.2 so that apps can tell that DeltaRectangles is usable
Let me know if there's anything I can do to help this occur.
[1] http://partiwm.org/wiki/xpra
Version: 7.3 (2007.09)
### Blocking
* [Bug 44202](https://bugs.freedesktop.org/show_bug.cgi?id=44202)Keith PackardKeith Packardhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/362Reimplement support for ctrl-alt-+/-2018-12-13T22:19:00ZBugzilla Migration UserReimplement support for ctrl-alt-+/-## Submitted by Samuel Thibault `@sthibaul`
Assigned to **Xorg Project Team**
**[Link to original bug (#14688)](https://bugs.freedesktop.org/show_bug.cgi?id=14688)**
## Description
When xrandr 1.2 was added, the support for ctrl-a...## Submitted by Samuel Thibault `@sthibaul`
Assigned to **Xorg Project Team**
**[Link to original bug (#14688)](https://bugs.freedesktop.org/show_bug.cgi?id=14688)**
## Description
When xrandr 1.2 was added, the support for ctrl-alt-+/- shortcut for
cycling between the available modes was dropped.
This is a feature that people with low vision appreciate because it is
very simple to get working, as opposed to software magnification (which
btw may burn quite some CPU, while we have the more-than-efficient
hardware solution above). That's also quite useful for quickly zooming
a part of the screen during a conference, so that people in the back
can see :)
On the xorg mailing list David Dusinow said that we `should be able
to do this today without bumping the protocol.', just a server patch.
When dealing with several screens, the principle could be to cycle
the mode of the screen which the cursor is currently in.
Version: git
### Blocking
* [Bug 44202](https://bugs.freedesktop.org/show_bug.cgi?id=44202)https://gitlab.freedesktop.org/xorg/xserver/-/issues/363XScreenSaverSuspend doesn't work as documented2018-12-13T22:19:09ZBugzilla Migration UserXScreenSaverSuspend doesn't work as documented## Submitted by Rui Tiago Matos
Assigned to **Xorg Project Team**
**[Link to original bug (#14802)](https://bugs.freedesktop.org/show_bug.cgi?id=14802)**
## Description
From the following mail:
http://lists.freedesktop.org/archive...## Submitted by Rui Tiago Matos
Assigned to **Xorg Project Team**
**[Link to original bug (#14802)](https://bugs.freedesktop.org/show_bug.cgi?id=14802)**
## Description
From the following mail:
http://lists.freedesktop.org/archives/xorg/2008-March/033491.html
Agreed. An XScreenSaver bug. At least here XScreenSaverSuspend( dpy, True )
does nothing[*] - the idle counter returned by XScreenSaverQueryInfo() does
not stop increasing, despite what the XScreenSaver manpage says. Which only
supports my point from the thread linked above that this extension is broken.
[*] The whole sequence is:
XScreenSaverQueryExtension( dpy, &dummy, &dummy );
XScreenSaverSuspend( dpy, True );
XSync( dpy, False );
sleep( 120 );
I can't see how I could possibly make any mistake here.https://gitlab.freedesktop.org/xorg/driver/xf86-video-sis/-/issues/4Support for SiS 662/6712018-08-10T20:47:18ZBugzilla Migration UserSupport for SiS 662/671## Submitted by Calorì Alessandro
Assigned to **Xorg Project Team**
**[Link to original bug (#14848)](https://bugs.freedesktop.org/show_bug.cgi?id=14848)**
## Description
Created attachment 14873
Intel patch against X.org SiS driv...## Submitted by Calorì Alessandro
Assigned to **Xorg Project Team**
**[Link to original bug (#14848)](https://bugs.freedesktop.org/show_bug.cgi?id=14848)**
## Description
Created attachment 14873
Intel patch against X.org SiS driver version 0.9.1
The current SiS driver, as well as older versions, doesn't provide good support for SiS 662/671-based video adapters. I own an Intel D201GLY2 with SiS 662FX video adapter and, when starting X.org with this driver, multiple flickering vertical lines are shown on the screen. The only way to use X.org without them is either to reduce the resolution to 800x600 or the color depth to 8 bit.
Intel has released a modified driver that works good even at high resolutions (1680x1050) and with high color depths (24 bit).
The problem occurs on different platforms (I've tried x86 and x86_64), on different OS (I've tried various Linux distro and FreeBSD) and different driver versions (I've tried 0.9.1, 0.9.3 and 0.9.4).
I attach a patch for X.org driver version 0.9.1 made against the Intel driver, based on that exact version (so that only Intel changes are shown).
It is also being reported that the problem occurs on Intel D201GLY.
**Patch 14873**, "Intel patch against X.org SiS driver version 0.9.1":
[intel.patch.bz2](/uploads/413abb6e2b3887cb61148b72647f4e03/intel.patch.bz2)
### See also
* http://bugs.freedesktop.org/show_bug.cgi?id=9409