Bug#832432: xserver-xorg-core: Intel Graphics Gen4 modesetting driver regressions
I just posted at https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1606103 that the problem seems to be in hw/xfree86/drivers/modesetting/drmmode_display.c#add_gtf_modes(), which is forcing a maximum vertical refresh of 60 (plus 1%), even though my monitor can actually do up to 120, and so any modelines with a refresh above this are being flagged as out of range and being pruned later. It looks like the function that calls add_gtf_modes() has access to the monitor info, including vertical refresh, so a solution might be to pass the info to add_gtf_modes() and have add_gtf_modes() use this maximum refresh. That's assuming that add_gtf_modes() is being called once per monitor rather than for all monitors.
Bug#2297: Easy repro plan for oldest bug in Debian :-)
1. Open an xterm. This will be the "fast xterm". 2. Open a second xterm. This will be the "managing xterm". 3. In the managing, xterm, do ssh -X localhost And log in as necessary. This will provide you with a shell session with X environemtn variables arranging indirection through the ssh running in the managing xterm. 4. In the remote shell in the managing xterm, type xterm This generates a new xterm. This will be the "slow xterm". 5. In the slow xterm, select some text. Double clicking on some bit of the prompt will do. 6. In the managing xterm, type ~ ^Z This suspends the ssh session. The slow xterm becomes frozen - avoid interacting with it. 7. In the fast xterm, press Shift+Insert and then type some text. You will see the text echoed immediately. 8. In the managing xterm, type fg The slow xterm wakes up, and now the selected text will appear in the fast xterm, out of order. This procedure ought to work to test for this bug with any program which can work over a forwarded X connection. Note that for the but to occur, the "slow xterm" does not need to be a terminal program at all. I often experience the bug (I did, in fact, just this morning) with a web browser as the "slow" program. Web browsers are often preoccupied with rendering kittens and leaking memory, so c&p from a web browser into a shell often provides a good opportunity for this mispaste race. I think xterm should buffer the input until the selection arrives. There should be a timeout which should be configurable. If the timeout occurs, I guess the buffered input should be discarded and the bell should be rung. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Processed: Fix email address
Processing commands for cont...@bugs.debian.org: > submitter 2297 ijack...@chiark.greenend.org.uk Bug #2297 [xterm] xterm: xterm sometimes gets mouse-paste and RETURN keypress in wrong order Changed Bug submitter to 'ijack...@chiark.greenend.org.uk' from 'i...@chiark.greenend.org.uk'. > -- Stopping processing here. Please contact me if you need assistance. -- 2297: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=2297 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: your mail
Processing commands for cont...@bugs.debian.org: > tags 810913 - moreinfo Bug #810913 [mesa] mesa: Enable OpenCL on ppc64el Removed tag(s) moreinfo. > End of message, stopping processing here. Please contact me if you need assistance. -- 810913: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810913 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#832954: xwd does not interact well with i3
Package: x11-apps
Severity: minor
Version: 7.7+6
Tags: patch
Hi,
xwd cannot cope with the way i3 sets up the window hierarchy. Attempting
a root window grab results in:
=
jcn@inti:/tmp$ xwd -root > /dev/null
X Error of failed request: BadColor (invalid Colormap parameter)
Major opcode of failed request: 91 (X_QueryColors)
Resource id in failed request: 0x0
Serial number of failed request: 166
Current serial number in output stream: 166
=
... due to, somewhere along the tree:
=
jcn@inti:/tmp$ xwininfo -id 0x80085e
xwininfo: Window id: 0x80085e "[i3 con] workspace 9"
Absolute upper-left X: 0
Absolute upper-left Y: 0
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 1600
Height: 18
Depth: 32
Visual: 0x7c
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x0 (not installed)
[...]
=
Specifying '-icmap' does not help as the failing call to XQueryColors()
is not the one in xwd/xwd.c, but the one in xwd/multiVis.c (which is not
affected by '-icmap').
A proper fix would probably be to make the "use_installed" boolean non-static
and copy the full logic from xwd.c:596 to multiVis.c:236 (or preferably to
line 302, where the image_region_type and thus also the WindowID is still
available).
My quick-and-dirty patch at least fixes the symptom, but is only half the
story.
Thanks for considering,
Jan
--
Jan Nordholz
Security in Telecommunications
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
phone: +49 30 8353 58663
--- a/xwd/multiVis.c 2013-08-09 06:12:24.0 +0200
+++ b/xwd/multiVis.c 2016-07-30 02:58:54.879020723 +0200
@@ -299,6 +299,10 @@
XColor *colors;
int rShift = 0, gShift = 0, bShift = 0;
+if (reg->cmap == 0) {
+ reg->cmap = XListInstalledColormaps(disp, reg->win, &i)[0];
+}
+
QueryColorMap(disp,reg->cmap,reg->vis,&colors,
&rShift,&gShift,&bShift) ;
