Re: [PATCH] xfree86: add default modes for 16:9 and 16:10

2018-01-16 Thread Martin Wilck 
On Tue, 2018-01-09 at 20:33 +0100, Martin Wilck wrote:
> Improve the user experience for users with wide screens by adding
> standard
> 16:9 and 16:10 modes to extramodes, as suggested previously
> (https://lists.x.org/archives/xorg-devel/2016-February/048866.html).
> Tested successfully on my laptop. Feedback welcome.
> 
> See also https://bugs.freedesktop.org/show_bug.cgi?id=37858.
> 
> Signed-off-by: Martin Wilck 
> ---
>  hw/xfree86/common/extramodes | 142
> +++
>  1 file changed, 142 insertions(+)

No opinions on this patch?

Regards
Martin

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] xfree86: add default modes for 16:9 and 16:10

2018-01-09 Thread Martin Wilck 
Improve the user experience for users with wide screens by adding standard
16:9 and 16:10 modes to extramodes, as suggested previously
(https://lists.x.org/archives/xorg-devel/2016-February/048866.html).
Tested successfully on my laptop. Feedback welcome.

See also https://bugs.freedesktop.org/show_bug.cgi?id=37858.

Signed-off-by: Martin Wilck 
---
 hw/xfree86/common/extramodes | 142 +++
 1 file changed, 142 insertions(+)

diff --git a/hw/xfree86/common/extramodes b/hw/xfree86/common/extramodes
index 450502670286..5a446938250f 100644
--- a/hw/xfree86/common/extramodes
+++ b/hw/xfree86/common/extramodes
@@ -25,3 +25,145 @@ Modeline "2048x1536" 340.48  2048 2216 2440 2832  1536 1537 
1540 1603 -hsync +vs
 # 2048x1536 @ 85Hz (VESA GTF) hsync: 137.0kHz
 Modeline "2048x1536" 388.04  2048 2216 2440 2832  1536 1537 1540 1612 -hsync 
+vsync
 
+### 16:9 modelines generated by cvt
+
+# 640x360 59.32 Hz (CVT 0.23M9-R) hsync: 22.19 kHz; pclk: 17.75 MHz
+Modeline "640x360R"   17.75  640 688 720 800  360 363 368 374 +hsync -vsync
+
+# 640x360 59.84 Hz (CVT 0.23M9) hsync: 22.50 kHz; pclk: 18.00 MHz
+Modeline "640x360"   18.00  640 664 720 800  360 363 368 376 -hsync +vsync
+
+# 720x405 58.99 Hz (CVT 0.29M9-R) hsync: 24.72 kHz; pclk: 21.75 MHz
+Modeline "720x405R"   21.75  720 768 800 880  405 408 413 419 +hsync -vsync
+
+# 720x405 59.51 Hz (CVT 0.29M9) hsync: 25.11 kHz; pclk: 22.50 MHz
+Modeline "720x405"   22.50  720 744 808 896  405 408 413 422 -hsync +vsync
+
+# 864x486 59.57 Hz (CVT 0.42M9-R) hsync: 29.79 kHz; pclk: 30.50 MHz
+Modeline "864x486R"   30.50  864 912 944 1024  486 489 494 500 +hsync -vsync
+
+# 864x486 59.92 Hz (CVT 0.42M9) hsync: 30.32 kHz; pclk: 32.50 MHz
+Modeline "864x486"   32.50  864 888 968 1072  486 489 494 506 -hsync +vsync
+
+# 960x540 59.82 Hz (CVT 0.52M9-R) hsync: 33.26 kHz; pclk: 37.25 MHz
+Modeline "960x540R"   37.25  960 1008 1040 1120  540 543 548 556 +hsync -vsync
+
+# 960x540 59.63 Hz (CVT 0.52M9) hsync: 33.51 kHz; pclk: 40.75 MHz
+Modeline "960x540"   40.75  960 992 1088 1216  540 543 548 562 -hsync +vsync
+
+# 1024x576 59.82 Hz (CVT 0.59M9-R) hsync: 35.47 kHz; pclk: 42.00 MHz
+Modeline "1024x576R"   42.00  1024 1072 1104 1184  576 579 584 593 +hsync 
-vsync
+
+# 1024x576 59.90 Hz (CVT 0.59M9) hsync: 35.88 kHz; pclk: 46.50 MHz
+Modeline "1024x576"   46.50  1024 1064 1160 1296  576 579 584 599 -hsync +vsync
+
+# 1280x720 59.74 Hz (CVT 0.92M9-R) hsync: 44.27 kHz; pclk: 63.75 MHz
+Modeline "1280x720R"   63.75  1280 1328 1360 1440  720 723 728 741 +hsync 
-vsync
+
+# 1280x720 59.86 Hz (CVT 0.92M9) hsync: 44.77 kHz; pclk: 74.50 MHz
+Modeline "1280x720"   74.50  1280 1344 1472 1664  720 723 728 748 -hsync +vsync
+
+# 1368x768 59.85 Hz (CVT) hsync: 47.28 kHz; pclk: 72.25 MHz
+Modeline "1368x768R"   72.25  1368 1416 1448 1528  768 771 781 790 +hsync 
-vsync
+
+# 1368x768 59.88 Hz (CVT) hsync: 47.79 kHz; pclk: 85.25 MHz
+Modeline "1368x768"   85.25  1368 1440 1576 1784  768 771 781 798 -hsync +vsync
+
+# 1600x900 59.82 Hz (CVT 1.44M9-R) hsync: 55.40 kHz; pclk: 97.50 MHz
+Modeline "1600x900R"   97.50  1600 1648 1680 1760  900 903 908 926 +hsync 
-vsync
+
+# 1600x900 59.95 Hz (CVT 1.44M9) hsync: 55.99 kHz; pclk: 118.25 MHz
+Modeline "1600x900"  118.25  1600 1696 1856 2112  900 903 908 934 -hsync +vsync
+
+# 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz
+Modeline "1920x1080R"  138.50  1920 1968 2000 2080  1080 1083 1088  +hsync 
-vsync
+
+# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
+Modeline "1920x1080"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync 
+vsync
+
+# 2048x1152 59.91 Hz (CVT 2.36M9-R) hsync: 70.99 kHz; pclk: 156.75 MHz
+Modeline "2048x1152R"  156.75  2048 2096 2128 2208  1152 1155 1160 1185 +hsync 
-vsync
+
+# 2048x1152 59.90 Hz (CVT 2.36M9) hsync: 71.58 kHz; pclk: 197.00 MHz
+Modeline "2048x1152"  197.00  2048 2184 2400 2752  1152 1155 1160 1195 -hsync 
+vsync
+
+# 2560x1440 59.95 Hz (CVT 3.69M9-R) hsync: 88.79 kHz; pclk: 241.50 MHz
+Modeline "2560x1440R"  241.50  2560 2608 2640 2720  1440 1443 1448 1481 +hsync 
-vsync
+
+# 2560x1440 59.96 Hz (CVT 3.69M9) hsync: 89.52 kHz; pclk: 312.25 MHz
+Modeline "2560x1440"  312.25  2560 2752 3024 3488  1440 1443 1448 1493 -hsync 
+vsync
+
+# 2880x1620 59.97 Hz (CVT 4.67M9-R) hsync: 99.92 kHz; pclk: 303.75 MHz
+Modeline "2880x1620R"  303.75  2880 2928 2960 3040  1620 1623 1628 1666 +hsync 
-vsync
+
+# 2880x1620 59.96 Hz (CVT 4.67M9) hsync: 100.67 kHz; pclk: 396.25 MHz
+Modeline "2880x1620"  396.25  2880 3096 3408 3936  1620 1623 1628 1679 -hsync 
+vsync
+
+# 3200x1800 59.94 Hz (CVT 5.76M9-R) hsync: 111.01 kHz; pclk: 373.00 MHz
+Modeline "3200x1800R"  373.00  3200 3248 3280 3360

[PATCH] [libX11/XCB] Thread starves in _XReply() while anohter thread executes _XReadEvents()

2016-07-20 Thread Martin Wilck 
Hello,

I encounter the following situation on my system reproduceably when I
run the synergy KVM switching software (server side).

Thread A is stuck in this call path:

XSync()
   _XReply()
// line 625 ff: wait for event_waiter to process first event
while(dpy->xcb->event_waiter)
{ /* need braces around ConditionWait */
 ConditionWait(dpy, dpy->xcb->event_notify);
}

I observe that this thread never leaves this while loop any more.

Thread B executes:

XIfEvent()
   _XReadEvents()

Until the event it's waiting for arrives, XIfEvent() calls
_XReadEvents() in a loop with the display lock held. _XReadEvents() only
releases the lock after setting dpy->xcb->event_waiter. Only after
re-acquiring the lock, it clears event_waiter and sends a broadcast for
the condition variable dpy->xcb->event_notify.

In this situation, thread A is effectively blocked: ConditionWait()
receives the broadcast, but before it can acquire the display lock and
return, _XReadEvents() will have set event_waiter once more, so it needs
to wait again.

This goes on forever unless the event XIfEvent() is waiting for arrives.
In some situations, this seems to take a forever too, I'm not sure why
(maybe we are looking at a deadlock situation here in the sense that the
expected condition can't happen unless thread A gets a chance to run).

I am attaching a tentative patch that I've come up with. Please review
it. The rationale is to yield to a request waiter after grabbing one
event. I am currently testing it on my system (too early to come to a
conclusion though, at least it doesn't seem to have caused a regression
so far).

CC'ing Jamey who seems to be the expert on XCB locking matters.

The thread
https://groups.google.com/forum/#!topic/synergy-users/4O_Xod9HV-A
suggests that other people are seeing the same problem. It also suggests
that this only occurs wiht recent versions of synergy. However, IMO the
above analysis rather indicates a general XCB problem. Please comment.

Regards
Martin

--- libX11-1.6.3/src/xcb_io.c	2015-03-09 23:28:45.0 +0100
+++ libX11-1.6.3mw/src/xcb_io.c	2016-07-20 08:59:17.676070822 +0200
@@ -424,12 +424,15 @@
 		response = poll_for_response(dpy);
 		if(response)
 			handle_response(dpy, response, False);
-		else if(dpy->xcb->pending_requests->reply_waiter)
+		else if(!dpy->xcb->pending_requests->reply_waiter)
+			_XIOError(dpy);
+
+		/* If there is a reply waiter, give him a chance to run. */
+
+		if(dpy->xcb->pending_requests && dpy->xcb->pending_requests->reply_waiter)
 		{ /* need braces around ConditionWait */
 			ConditionWait(dpy, dpy->xcb->reply_notify);
 		}
-		else
-			_XIOError(dpy);
 	}
 
 	/* The preceding loop established that there is no
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel