GNOME Bugzilla – Bug 655041
missing refresh rate selection
Last modified: 2016-09-01 18:35:36 UTC
Hello, I have noticed that I can't change the refresh rate since the update to Gnome 3 (I am using the Archlinux distro) As I understand, the display tool is just a graphical frontend to xrandr, which hasn't changed in any way, so I guess that removal of the refresh rate selection option has been done for the sake of simplicity under the assumption that most people have mostly LCDs nowadays. Needless to say, this botheres me as I have a high-quality CRT and I have to call xrandr everytime I change the resolution. If you want to be simple, what about options like "Choose the highest (good for CRTs)" or "Choose the lowest (for LCDs)" and "Choose custom refresh rate" so people can get what they want.
commit 83bac646abd05b62fba7aae8eb4397e9a3c1bcb2 Author: Bastien Nocera <hadess@hadess.net> Date: Fri Aug 26 21:11:35 2011 +0100 display: Prefer higher frequency modes And prefer the preferred mode to other modes with the same resolution (even if they have a lower resolution). https://bugzilla.gnome.org/show_bug.cgi?id=655041
Always selecting the highest refresh rate doesn't work for LCD screens. On the two machines I have, which have LCD screens connected to the VGA output, the visual quality is noticeably better when using 60 HZ as the refresh rate than when 75 Hz is selected.
(In reply to comment #2) > Always selecting the highest refresh rate doesn't work for LCD screens. > > On the two machines I have, which have LCD screens connected to the VGA output, > the visual quality is noticeably better when using 60 HZ as the refresh rate > than when 75 Hz is selected. xrandr with no options will show you what is the preferred mode for each display. The preferred mode is not always the highest refresh available. For instance: HDMI1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1280x960 60.0 1152x864 75.0 1280x720 60.0 1024x768 75.1 70.1 66.0 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 shows the preferred mode (+) is 60hz for my LCD display. The same if I connect it to its VGA interface: VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1280x960 60.0 1152x864 75.0 1280x720 60.0 1024x768 75.1 70.1 66.0 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 FWIW, I can use either 60hz or 75hz HDMI with no problem. However, the display it unusable if I try 75Hz with the VGA interface (it gets blurry). Nevertheless, the preferred mode is a different issue.
It just happened to me that a projector connected to the external VGA had weird stripes because of a too high refresh rate. Any chance we could go back listing all available refresh rates?
Bug still present in control-center-3.4.2-4.fc17.x86_64 Use case: My laptop refresh rate, as for most monitors, is 60Hz. However PAL DVDs and DVB videos are encoded at 50Hz. When I plug my laptop into my TV over HDMI it defaults to 60Hz, so these videos are very juddery (trying to display 50Hz source at 60Hz). Setting the TV display using xrandr --rate 50 completely fixes the problem. There is no mechanism to set this through control-center. I suppose the other solution might be to note the current region, lookup whether it's a PAL or NTSC region, and have a more sensible default for TVs (60Hz is definitely the wrong default for a TV in the UK).
(In reply to comment #4) > It just happened to me that a projector connected to the external VGA had weird > stripes because of a too high refresh rate. > > Any chance we could go back listing all available refresh rates? The fix would be to have X.org blacklist the higher rate for that device. (In reply to comment #5) > Bug still present in control-center-3.4.2-4.fc17.x86_64 > > Use case: My laptop refresh rate, as for most monitors, is 60Hz. However PAL > DVDs and DVB videos are encoded at 50Hz. When I plug my laptop into my TV over > HDMI it defaults to 60Hz, so these videos are very juddery (trying to display > 50Hz source at 60Hz). Setting the TV display using xrandr --rate 50 completely > fixes the problem. > > There is no mechanism to set this through control-center. > > I suppose the other solution might be to note the current region, lookup > whether it's a PAL or NTSC region, and have a more sensible default for TVs > (60Hz is definitely the wrong default for a TV in the UK). I empathise with the problem, but it should really work out of the box. Totem can tell the compositor it needs a multiple of 25fps as a frequency, and the change would happen on-the-fly, and without tweaking. In both cases, editing ~/.config/monitors.xml makes for a permanent change, and poking at xrandr on the command-line for a more temporary one.
Bastien, I fully agree with the 'this should work out of the box' but in reality there are much more variables out there to consider. For example, at Europython 2012 they had framegrabber USB devices to mix the camera recordings with the VGA output. They specifically requested each speaker to run the external connector at 60Hz to avoid grabbing issues, despite the projector itself was pretty happy even at 75Hz. Besides, I found weird that we usually look at what other platforms do or don't when preparing design documents, but none of them hide the frequency selection.
Bastien, I just had the exemple at the begining of the month for Ohm2013. we used HDMI->SDI converters, which advertise just about any resolution, obviously, but you want to select the right frequency for the device at the other end (sdi switcher) to work properly. So, one MUST be able to choose the proper refresh rate, and it SHOULD be possible to do so within the graphical interface, without resorting to hacking monitors.xml
Another data point - this recently broke for me using an HDMI screen at the end of a long cable, 75Hz was unstable but 60Hz worked fine.
Setting the refresh rate is one of the tentative goals of the new display design, so it's clearly something that's simply missing from the current implementation.
I'd like to add that this doesn't just affect CRTs and projectors. I have a 144Hz LCD and Gnome picks 59.95Hz. If I'm reading the xrandr output correctly the 144 is set as the preferred, but it still drops to 60Hz as soon as Gnome starts. This behavior is not seen in KDE. I am able to change refresh rates in gnome with nvidia-settings, lxrandr or xrandr directly without issue. $ xrandr Screen 0: minimum 8 x 8, current 2560 x 1440, maximum 16384 x 16384 DVI-I-0 disconnected (normal left inverted right x axis y axis) DVI-I-1 disconnected (normal left inverted right x axis y axis) HDMI-0 disconnected (normal left inverted right x axis y axis) DP-0 disconnected (normal left inverted right x axis y axis) DVI-D-0 disconnected (normal left inverted right x axis y axis) DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 2560x1440 59.95 + 144.00* 120.00 99.95 84.98
Created attachment 300302 [details] [review] display: Don't leak GnomeRRModes GnomeRRMode is a boxed type which means that if stored as such in a tree model, the model creates a copy to use internally. In addition, it means that gtk_tree_model_get() will also get a copy which must be freed by the caller which we were not doing. In this case though, we don't need the copies since all the GnomeRRModes that we use outlive the model so we can simplify things by just storing a plain pointer in the model instead.
Created attachment 300303 [details] [review] display: Add a way to specify the monitor refresh rate This adds an extra frequency combo box that allows users to choose a frequency for a given resolution. We still keep the previous automatically chosen frequency behavior by default for users who don't care about this parameter.
Created attachment 300361 [details] [review] display: Close the dialog when the RR configuration changes We assume that the RR configuration is valid in various callbacks from both our modal dialogs which doesn't hold if there's an hotplug while a dialog is open (e.g. monitor is plugged/unplugged). Closing the dialog in that case seems the right thing to do since it would be operating on an outdated view of the world otherwise and likely end up crashing. -- Note that even though attachment 300302 [details] [review] makes this issue worse, it was there already and we should be doing this anyway.
Created attachment 300446 [details] [review] display: Fix GtkListStore leaks in setup dialog
Review of attachment 300446 [details] [review]: I'll fix master first and then fold the other leak fix into the patch I'm proposing here
Created attachment 300451 [details] [review] display: Fix GtkListStore leak in setup dialog
Created attachment 300452 [details] [review] display: Don't leak GnomeRRModes -- rebased
Created attachment 300453 [details] [review] display: Add a way to specify the monitor refresh rate -- rebased - leak fixed
Created attachment 300454 [details] [review] display: Close the dialog when the RR configuration changes -- rebased
With those patches, it crashes when clicking on one of the displays listed:
+ Trace 234954
Review of attachment 300451 [details] [review]: Sure.
Review of attachment 300452 [details] [review]: Sure.
Review of attachment 300453 [details] [review]: ::: panels/display/cc-display-panel.c @@ +1738,3 @@ + + res = make_resolution_string (resolution_mode); + if ((l = g_hash_table_lookup (priv->res_freqs, res)) != NULL) That doesn't quite work as expected. The builtin monitor of my laptop shows 2 entries, "Auto" and "59Hz", but there's only one frequency available for this resolution: LVDS1 connected 1600x900+0+180 (normal left inverted right x axis y axis) 309mm x 174mm 1600x900 59.97*+ 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 And for my external screen, I get offered loads of frequencies, including "29Hz" and "25Hz", but those don't show up as available in xrandr: HDMI1 connected primary 1920x1080+1600+0 (normal left inverted right x axis y axis) 509mm x 286mm 1920x1080 60.00 + 50.00 59.94* 1920x1080i 60.00 50.00 59.94 1600x900 59.98 1280x1024 75.02 60.02 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 60.00 800x600 75.00 60.32 720x576 50.00 720x576i 50.00 720x480 60.00 59.94 720x480i 60.00 59.94 640x480 75.00 60.00 59.94 720x400 70.08
Review of attachment 300454 [details] [review]: Sure.
Pushing the acked bug fixes to master and gnome-3-14 Attachment 300451 [details] pushed as c730ebc - display: Fix GtkListStore leak in setup dialog Attachment 300452 [details] pushed as a963a9c - display: Don't leak GnomeRRModes Attachment 300454 [details] pushed as 75cb96d - display: Close the dialog when the RR configuration changes
Created attachment 302087 [details] [review] display: Separate interlaced from normal modes
Created attachment 302088 [details] [review] rr: Add flags to GnomeRRMode
Created attachment 302089 [details] [review] backends: Add flags to MetaMonitorMode -- Can you try these patches for mutter, gnome-desktop and g-c-c and tell me if it behaves as you'd expect on your HDMI display?
Created attachment 304072 [details] [review] rr: Add flags to GnomeRRMode -- Rebased. BTW, I wonder if it's worth it to introduce a new dbus method GetResources2() and keep the old one with mode flags to keep compatibility? Otherwise we'd need a sync release of mutter and gnome-desktop. This dbus API isn't considered public though AFAIU so it shouldn't be a problem from that angle.
Created attachment 304074 [details] [review] display: Add a way to specify the monitor refresh rate -- rebased
Created attachment 304075 [details] [review] backends: Add flags to MetaMonitorMode -- rebased
Created attachment 304076 [details] [review] display: Separate interlaced from normal modes -- rebased
As mentioned on IRC, I would prefer it if, for setups like mine where there's only one frequency to select from, not to see the drop-down at all. Screen 0: minimum 8 x 8, current 3520 x 1080, maximum 32767 x 32767 LVDS1 connected 1600x900+0+180 (normal left inverted right x axis y axis) 309mm x 174mm 1600x900 59.97*+ 1368x768 60.00 1280x720 60.00 1024x768 60.00 1024x576 60.00 960x540 60.00 800x600 60.32 56.25 864x486 60.00 800x450 60.00 640x480 59.94 720x405 60.00 640x360 60.00 Here, the panel was offering "59Hz" and "Auto".
Review of attachment 304072 [details] [review]: gnome-rr-debug should be expanded to include that information about available modes.
Created attachment 304194 [details] [review] rr: Add flags to GnomeRRMode -- Added mode listing
Created attachment 304195 [details] [review] display: Add a way to specify the monitor refresh rate This adds an extra frequency combo box that allows users to choose a frequency for a given resolution. -- Ok, I removed the Auto option and just pre-select the frequency for the current mode if the selected resolution is the current one, otherwise we default to select the first frequency for the mode.
Created attachment 304261 [details] [review] display: Add a way to specify the monitor refresh rate -- Forgot to hide the frequency selection when there's only on option. Done now.
Review of attachment 304194 [details] [review]: This looks good.
Review of attachment 304261 [details] [review]: That looks good as well. Only thing to do is to double-check whether having both "60Hz" and "59.94Hz" as frequencies is actually useful, as advertised by xrandr: HDMI1 connected primary 1920x1080+1600+0 (normal left inverted right x axis y axis) 509mm x 286mm 1920x1080 60.00 + 50.00 59.94* Ideally, I would have preferred it if applications could export what their "native" framerate is, so that launching Totem with a cinema film would (flicker-free) switch to 50Hz for that output so that it's a multiple of the media we're trying to display, but that's a whole other kettle of fish.
Review of attachment 304076 [details] [review]: Looks good, until we can build without X11 support, at which point we'll need to replace that enum flag definition.
Dave, Adam, any ideas what comment 40 might be about?
(In reply to Bastien Nocera from comment #42) > Dave, Adam, any ideas what comment 40 might be about? xrandr --verbose please? The 59.94Hz timing is probably from a CEA descriptor block, which means it has large enough blanking intervals to encode useful amounts of HDMI audio; the 60Hz timing is probably the same as the one generated by the CVT-R timing formula, which means it has very little blanking bandwidth indeed.
(In reply to Adam Jackson from comment #43) > (In reply to Bastien Nocera from comment #42) > > Dave, Adam, any ideas what comment 40 might be about? > > xrandr --verbose please? HDMI1 connected primary 1920x1080+1600+0 (0x113) normal (normal left inverted right x axis y axis) 509mm x 286mm Identifier: 0x45 Timestamp: 1040426 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: VGA1 CRTC: 0 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: _MUTTER_PRESENTATION_OUTPUT: 0 EDID: 00ffffffffffff0010ac84404c5a3044 1917010380331d78ea6431a35751a227 0f5054a54b00714f8180a9c0d1c00101 010101010101023a801871382d40582c 4500fd1e1100001e000000ff00375630 445833364d44305a4c0a000000fc0044 454c4c205332333430540a20000000fd 00384c1e5111000a2020202020200125 020326f14f9005040302071601061112 1513141f2309070765030c0010008301 0000e3050301023a801871382d40582c 4500fd1e1100001e011d8018711c1620 582c2500fd1e1100009e011d007251d0 1e206e285500fd1e1100001e8c0ad08a 20e02d10103e9600fd1e110000180000 000000000000000000000000000000c5 aspect ratio: Automatic supported: Automatic, 4:3, 16:9 Broadcast RGB: Automatic supported: Automatic, Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on 1920x1080 (0x111) 148.500MHz +HSync +VSync +preferred h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.50KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.00Hz 1920x1080 (0x112) 148.500MHz +HSync +VSync h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.25KHz v: height 1080 start 1084 end 1089 total 1125 clock 50.00Hz 1920x1080 (0x113) 148.352MHz +HSync +VSync *current h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.43KHz v: height 1080 start 1084 end 1089 total 1125 clock 59.94Hz 1920x1080i (0x114) 74.250MHz +HSync +VSync Interlace h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 33.75KHz v: height 1080 start 1084 end 1094 total 1125 clock 60.00Hz 1920x1080i (0x115) 74.250MHz +HSync +VSync Interlace h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 28.12KHz v: height 1080 start 1084 end 1094 total 1125 clock 50.00Hz 1920x1080i (0x116) 74.176MHz +HSync +VSync Interlace h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 33.72KHz v: height 1080 start 1084 end 1094 total 1125 clock 59.94Hz 1600x900 (0x117) 118.963MHz -HSync +VSync h: width 1600 start 1696 end 1864 total 2128 skew 0 clock 55.90KHz v: height 900 start 901 end 904 total 932 clock 59.98Hz 1280x1024 (0x118) 135.000MHz +HSync +VSync h: width 1280 start 1296 end 1440 total 1688 skew 0 clock 79.98KHz v: height 1024 start 1025 end 1028 total 1066 clock 75.02Hz 1280x1024 (0x119) 108.000MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 63.98KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.02Hz 1152x864 (0x11a) 108.000MHz +HSync +VSync h: width 1152 start 1216 end 1344 total 1600 skew 0 clock 67.50KHz v: height 864 start 865 end 868 total 900 clock 75.00Hz 1280x720 (0x11b) 74.250MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 45.00KHz v: height 720 start 725 end 730 total 750 clock 60.00Hz 1280x720 (0x11c) 74.250MHz +HSync +VSync h: width 1280 start 1720 end 1760 total 1980 skew 0 clock 37.50KHz v: height 720 start 725 end 730 total 750 clock 50.00Hz 1280x720 (0x11d) 74.176MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 44.96KHz v: height 720 start 725 end 730 total 750 clock 59.94Hz 1024x768 (0x11e) 78.800MHz +HSync +VSync h: width 1024 start 1040 end 1136 total 1312 skew 0 clock 60.06KHz v: height 768 start 769 end 772 total 800 clock 75.08Hz 1024x768 (0xc2) 65.000MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz v: height 768 start 771 end 777 total 806 clock 60.00Hz 800x600 (0x11f) 49.500MHz +HSync +VSync h: width 800 start 816 end 896 total 1056 skew 0 clock 46.88KHz v: height 600 start 601 end 604 total 625 clock 75.00Hz 800x600 (0xc5) 40.000MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew 0 clock 37.88KHz v: height 600 start 601 end 605 total 628 clock 60.32Hz 720x576 (0x120) 27.000MHz -HSync -VSync h: width 720 start 732 end 796 total 864 skew 0 clock 31.25KHz v: height 576 start 581 end 586 total 625 clock 50.00Hz 720x576i (0x121) 13.500MHz -HSync -VSync Interlace h: width 720 start 732 end 795 total 864 skew 0 clock 15.62KHz v: height 576 start 580 end 586 total 625 clock 50.00Hz 720x480 (0x122) 27.027MHz -HSync -VSync h: width 720 start 736 end 798 total 858 skew 0 clock 31.50KHz v: height 480 start 489 end 495 total 525 clock 60.00Hz 720x480 (0x123) 27.000MHz -HSync -VSync h: width 720 start 736 end 798 total 858 skew 0 clock 31.47KHz v: height 480 start 489 end 495 total 525 clock 59.94Hz 720x480i (0x124) 13.513MHz -HSync -VSync Interlace h: width 720 start 739 end 801 total 858 skew 0 clock 15.75KHz v: height 480 start 488 end 494 total 525 clock 60.00Hz 720x480i (0x125) 13.500MHz -HSync -VSync Interlace h: width 720 start 739 end 801 total 858 skew 0 clock 15.73KHz v: height 480 start 488 end 494 total 525 clock 59.94Hz 640x480 (0x126) 31.500MHz -HSync -VSync h: width 640 start 656 end 720 total 840 skew 0 clock 37.50KHz v: height 480 start 481 end 484 total 500 clock 75.00Hz 640x480 (0x127) 25.200MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.50KHz v: height 480 start 490 end 492 total 525 clock 60.00Hz 640x480 (0xc9) 25.175MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.47KHz v: height 480 start 490 end 492 total 525 clock 59.94Hz 720x400 (0x128) 28.320MHz -HSync +VSync h: width 720 start 738 end 846 total 900 skew 0 clock 31.47KHz v: height 400 start 412 end 414 total 449 clock 70.08Hz > The 59.94Hz timing is probably from a CEA descriptor block, which means it > has large enough blanking intervals to encode useful amounts of HDMI audio; > the 60Hz timing is probably the same as the one generated by the CVT-R > timing formula, which means it has very little blanking bandwidth indeed. Which means that we should automatically use the 59.94Hz frequency when HDMI audio is being used, right? I wonder at what level of the stack we're supposed to be handling this...
*** Bug 750314 has been marked as a duplicate of this bug. ***
(In reply to Bastien Nocera from comment #44) > 1920x1080 (0x111) 148.500MHz +HSync +VSync +preferred > h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.50KHz > v: height 1080 start 1084 end 1089 total 1125 clock 60.00Hz Interestingly the preferred mode does not match the CVT formula: dmt:~% cvt -r 1920 1080 # 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 1111 +hsync -vsync dmt:~% cvt 1920 1080 # 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync > 1920x1080 (0x113) 148.352MHz +HSync +VSync *current > h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.43KHz > v: height 1080 start 1084 end 1089 total 1125 clock 59.94Hz ... but it does have the same timing numbers (except for dot clock) as the CEA 59.94Hz mode. > > The 59.94Hz timing is probably from a CEA descriptor block, which means it > > has large enough blanking intervals to encode useful amounts of HDMI audio; > > the 60Hz timing is probably the same as the one generated by the CVT-R > > timing formula, which means it has very little blanking bandwidth indeed. > > Which means that we should automatically use the 59.94Hz frequency when HDMI > audio is being used, right? I wonder at what level of the stack we're > supposed to be handling this... It's more about the relative size of the blanking interval than the refresh rate. For this particular monitor it looks like the preferred mode includes audio bandwidth already. As for what level of the stack to handle this at... good question.
Where does that leave us with regards to Rui's patches?
So is this issue going to get fixed or what? I have a 144Hz monitor. It'd be nice if Gnome recognized that.
(In reply to Nathan Best from comment #48) > So is this issue going to get fixed or what? I have a 144Hz monitor. It'd be > nice if Gnome recognized that. Patches are available for you to use and test. I'm not happy with the patches because they expose refresh rates which are too close to be useful to users.
(In reply to Nathan Best from comment #48) > So is this issue going to get fixed or what? I have a 144Hz monitor. It'd be > nice if Gnome recognized that. I feel your pain, man. I have a VG248QE monitor which defaults to 60hz for some reason. It would be really nice to change it to 144hz so I can get my moneys worth. Sure some would say to just use xrandr to change it, but what about wayland? As far as I know, there isn't a way to change your refresh rate in wayland since the compositor should handle that. The gnome guys need to provide a way to change your refresh rate instead of just relying on whatever it defaults to.(the defaults aren't always the best) This has been a problem for me for ages now. It has caused me to switch distros every day it seemed, just to find one that worked with my monitor. So far, I have come up empty handed.
(In reply to Brandon Gandy from comment #50) > (In reply to Nathan Best from comment #48) > > So is this issue going to get fixed or what? I have a 144Hz monitor. It'd be > > nice if Gnome recognized that. > > I feel your pain, man. I have a VG248QE monitor which defaults to 60hz for > some > reason. It would be really nice to change it to 144hz so I can get my moneys > worth. > Sure some would say to just use xrandr to change it, but what about wayland? > > As far as I know, there isn't a way to change your refresh rate in wayland > since > the compositor should handle that. The gnome guys need to provide a way to > change > your refresh rate instead of just relying on whatever it defaults to.(the > defaults aren't always the best) > > This has been a problem for me for ages now. It has caused me to switch > distros every day it seemed, just to find one that worked with my monitor. > So far, I have come up empty handed. If it helps, XFCE and KDE are the two desktop environments which actually use the refresh rate you set in the Xorg configuration. Hopefully Gnome will have this issue fixed in 3.18.
I really hope this feature will finally be add to Gnome 3.20. We should be able to select the display frequency from the display manager. An obvious example of where this feature is mandatory is when you want to watch a movie. Your PC is linked to your TV and to enjoy your movie without any stutter / judder and perfect fluidity you have to set the TV frequency accordingly to the movie frames per second (eg. 23.976fps => 23.976Hz). Now it's impossible to do it in Gnome without a xrandr command or a third party app. Not really user friendly :( Thank you.
We don't need more comments on how you need the feature, or how it would be nice if the feature was merged. You can test the patches if you want. Right now, we need technical expertise, so unless you're a graphics expert please don't add any more comments.
Like Nathan Best said we should look at the code of XFCE and KDE to see how they do it if we don't have this kind of expertise on Gnome.
I know that "We don't need more comments on how you need the feature" but since nobody here have the "technical expertise" do implement this perfectly I think we can add, at least temporarily, the patches that enable this feature. It's better to have something not perfect but that work rather than nothing.
Can we have an update for this please ? Thanks
the update is as always: Gnome-devs trying to be smarter than the user by hiding stuff. As to the comment #40: 59.94 is twice 30000/1001 refresh. So when monitor doesn't offer 29.97 mode, that is natural match. analyzing a specific monitor's timings and blocking integration of that feature because 60 and 59.94 are "too close" for that is pointless. Let the user decide whether it is worth switching. If you hide supported modes, it is of no help. Enough arguments have been brought up already, as even stated by Bastien. Signal conversion boxes being the most "serious". You're not asking for technical expertise, you're asking for the magic "do everything right" spell that doesn't exist. If you're afraid of users being confused, sort the list by "Comupter modes" and "Video playback modes" or "frequently used" or "useful modes" first and all the rest you think doesn't make sense at the end.. Just offer what xrandr offers and users will be happy. Those with the risk of getting confused by 60 and 59.94 being too close likely won't even bother to fire up the monitor configuration but just hit the external display-switch button on their laptop/be fine with the preferred mode and won't give the refresh rates a second look. Over-engineering at its best.
Created attachment 324030 [details] [review] rr: Also export the frequency as a floating point number It was getting truncated to an integer, which isn't precise enough in some cases.
Created attachment 324031 [details] [review] rr: Add flags to GnomeRRMode
Created attachment 324032 [details] [review] display: Add a way to specify the monitor refresh rate This adds an extra frequency combo box that allows users to choose a frequency for a given resolution.
(In reply to Christian Lohmaier from comment #58) > the update is as always: Gnome-devs trying to be smarter than the user by > hiding stuff. > > As to the comment #40: > 59.94 is twice 30000/1001 refresh. So when monitor doesn't offer 29.97 mode, > that is natural match. That explains nothing, but thanks. Rui, if we want to land this before 3.20, we should use a new call similar to GetResources() so that we don't break on older versions of mutter. A list of the changes compared to your patches: - avoid listing the 60Hz frequency if 59.94Hz is available, and call that latter frequency "60Hz (ATSC)" - rename the combo box to "Refresh Rate" - export the frequency as a double in addition to an integer - rebased the gnome-rr patch after we added support for tiled monitors
Thank you very very much Bastien ! Just a question, if 59.94Hz is available, 60Hz doesn't appear ? If I understood correctly that's not necessary to do that because they are both useful : http://www.tvtechnology.com/media-systems/0191/whats-the-difference-between-fps-and-fps/241737
(In reply to jeremy9856 from comment #63) > Just a question, if 59.94Hz is available, 60Hz doesn't appear ? Don't waste your time. They know better. They don't care that when using dual monitor and one supports only 60Hz, and the other 59.94 you'll get tearing when playing back video across the two no matter what. While it "explains nothing" to say 59.94 is multiple of 30000/1001 while 60Hz is not, nowhere is stated why it is a problem offering the choice to the user. At least it's done in a way that's easy to patch out in the code. Have to be lucky that a patch is accepted within less than 5 years since bug creation and 1 year since initial patch.. (and I really mean that, thanks a lot for bringing it to next release)
Comment on attachment 304075 [details] [review] backends: Add flags to MetaMonitorMode Removing this patch, it doesn't apply cleanly to mutter, and we'll want to do this in another development cycle.
Comment on attachment 304076 [details] [review] display: Separate interlaced from normal modes Obsolete the patch, this will need to go in a separate development cycle.
Comment on attachment 324031 [details] [review] rr: Add flags to GnomeRRMode Ditto.
Created attachment 324124 [details] [review] display: Add a way to specify the monitor refresh rate This adds an extra frequency combo box that allows users to choose a frequency for a given resolution.
Created attachment 324125 [details] [review] display: Remove duplicate non-ATSC/NTSC rates from the list When a mode has 2 very close refresh rates such as 59.94Hz and 60Hz, most of the time, we'll want the 59.94Hz version. Hide the "PC" 60Hz version and only show the 59.94Hz version in those cases, and mark the frequency as "60Hz (ATSC)" so that those knowledgeable know that it's really 59.94Hz, and doesn't confuse those who expect rates to be multiple of 30Hz or 25Hz. See also https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate Note that we also do this for half and double that rate, eg. close to ~30Hz and ~120Hz.
Which leaves us with 3 patches: - one to add the frequency drop-down (Rui's but one style fix, and changing the "Frequency" label to "Refresh Rate") - one to export the frequency as a float - one to not show "60Hz" and "59Hz" in the drop-down (yes, the frequency is clipped, so good luck figuring out what it corresponds to) Rui, can you please file a new bug against the cc for the interlaced flags?
Review of attachment 324030 [details] [review]: looks good, needs code freeze break exception in gnome-desktop
Created attachment 324127 [details] freq drop down screenshot
Review of attachment 324125 [details] [review]: ::: panels/display/cc-display-panel.c @@ +1743,3 @@ + + frequencies = g_hash_table_lookup (priv->res_freqs, res); + frequencies = g_slist_sort (frequencies, sort_frequencies); This will change the list in the hash table but you're not setting the new list head back into the hash table. I'd prefer that we copy the list first and sort the copy instead. @@ +1752,3 @@ + * https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate + * + * We also want to handle this for ~30Hz and ~120Hz */ This comment is puzzling in this place. Maybe move it to the loop in setup_frequency_combo_box() ? @@ +1753,3 @@ + * + * We also want to handle this for ~30Hz and ~120Hz */ + for (l = frequencies; l != NULL; l = l->next) g_slist_copy() ? but see above @@ +1826,3 @@ i++; } g_free (res); I'd like this g_free() to move up so that we free this temporary string right after get_frequencies_for_res() when we don't need it anymore. We are leaking the frequencies list now since it's a copy. Should free it here
(In reply to Bastien Nocera from comment #69) > When a mode has 2 very close refresh rates such as 59.94Hz and 60Hz, > most of the time, we'll want the 59.94Hz version. > > Hide the "PC" 60Hz version and only show the 59.94Hz version in those > cases, and mark the frequency as "60Hz (ATSC)" so that those > knowledgeable know that it's really 59.94Hz, and doesn't confuse those > who expect rates to be multiple of 30Hz or 25Hz. As surprising as it is for me it seems you are right. I can't find a definitive answer but after reading some articles and forum like this one (http://forums.guru3d.com/showthread.php?t=401883) it seems that 59.94Hz and 60Hz are the same. That said, that seem to be right up to 1080p. In UHD it seems to exist a real 60Hz value. Note that for 24Hz and 23.976Hz that is not the case since there is 23.976fps and 24fps Bluray.
(In reply to Rui Matos from comment #73) > Review of attachment 324125 [details] [review] [review]: > > ::: panels/display/cc-display-panel.c > @@ +1743,3 @@ > + > + frequencies = g_hash_table_lookup (priv->res_freqs, res); > + frequencies = g_slist_sort (frequencies, sort_frequencies); > > This will change the list in the hash table but you're not setting the new > list head back into the hash table. > > I'd prefer that we copy the list first and sort the copy instead. > > @@ +1752,3 @@ > + * https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate > + * > + * We also want to handle this for ~30Hz and ~120Hz */ > > This comment is puzzling in this place. Maybe move it to the loop in > setup_frequency_combo_box() ? > > @@ +1753,3 @@ > + * > + * We also want to handle this for ~30Hz and ~120Hz */ > + for (l = frequencies; l != NULL; l = l->next) > > g_slist_copy() ? but see above > > @@ +1826,3 @@ > i++; > } > g_free (res); > > I'd like this g_free() to move up so that we free this temporary string > right after get_frequencies_for_res() when we don't need it anymore. > > We are leaking the frequencies list now since it's a copy. Should free it > here Most of those were the results of my early code design choices :) Fixed in newer version.
Review of attachment 324124 [details] [review]: Only comment would be that the g_slist_append() usage is likely not super efficient, but it's not like we're handling gazillions of frequencies.
Created attachment 324163 [details] [review] display: Remove duplicate non-ATSC/NTSC rates from the list When a mode has 2 very close refresh rates such as 59.94Hz and 60Hz, most of the time, we'll want the 59.94Hz version. Hide the "PC" 60Hz version and only show the 59.94Hz version in those cases, and mark the frequency as "60Hz (ATSC)" so that those knowledgeable know that it's really 59.94Hz, and doesn't confuse those who expect rates to be multiple of 30Hz or 25Hz. See also https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate Note that we also do this for half and double that rate, eg. close to ~30Hz and ~120Hz.
Created attachment 324166 [details] [review] display: Remove duplicate non-ATSC/NTSC rates from the list When a mode has 2 very close refresh rates such as 59.94Hz and 60Hz, most of the time, we'll want the 59.94Hz version. Hide the "PC" 60Hz version and only show the 59.94Hz version in those cases, and mark the frequency as "60Hz (ATSC)" so that those knowledgeable know that it's really 59.94Hz, and doesn't confuse those who expect rates to be multiple of 30Hz or 25Hz. See also https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate Note that we also do this for half and double that rate, eg. close to ~30Hz and ~120Hz.
Changed "ATSC" to "NTSC" as I think that's more recognisable.
(In reply to jeremy9856 from comment #74) > (In reply to Bastien Nocera from comment #69) > > When a mode has 2 very close refresh rates such as 59.94Hz and 60Hz, > > most of the time, we'll want the 59.94Hz version. > > > > Hide the "PC" 60Hz version and only show the 59.94Hz version in those > > cases, and mark the frequency as "60Hz (ATSC)" so that those > > knowledgeable know that it's really 59.94Hz, and doesn't confuse those > > who expect rates to be multiple of 30Hz or 25Hz. > > As surprising as it is for me it seems you are right. I can't find a > definitive answer but after reading some articles and forum like this one > (http://forums.guru3d.com/showthread.php?t=401883) it seems that 59.94Hz and > 60Hz are the same. > > That said, that seem to be right up to 1080p. In UHD it seems to exist a > real 60Hz value. Note that for 24Hz and 23.976Hz that is not the case since > there is 23.976fps and 24fps Bluray. I haven't had the chance to experience any of those, but we can cross that divide when we get people experiencing problems with the design we're proposing, as separate bug fixes.
Created attachment 324170 [details] [review] display: Remove duplicate non-ATSC/NTSC rates from the list When a mode has 2 very close refresh rates such as 59.94Hz and 60Hz, most of the time, we'll want the 59.94Hz version. Hide the "PC" 60Hz version and only show the 59.94Hz version in those cases, and mark the frequency as "60Hz (ATSC)" so that those knowledgeable know that it's really 59.94Hz, and doesn't confuse those who expect rates to be multiple of 30Hz or 25Hz. See also https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate Note that we also do this for half and double that rate, eg. close to ~30Hz and ~120Hz.
Marked the frequency strings as to be translated (thanks afranke).
(In reply to Bastien Nocera from comment #80) > I haven't had the chance to experience any of those, but we can cross that > divide when we get people experiencing problems with the design we're > proposing, as separate bug fixes. It's good to simplify the feature by hiding the "duplicates" frequencies but it's not very smart to hide the useful one. It's also not really fair to wait for people that complain that there is some missing frequencies whereas we already have them. Here is the Bluray frequencies: https://en.wikipedia.org/wiki/Blu-ray#Video No 60Hz (it really don't seems to exist up to 1080p) but 23.976Hz and 24Hz exist. Here is the UHD (4K) frequencies: http://www.safe.fr.cr/Temp/Hifi/UHDTV%20fr%e9q.jpg http://forum.hardware.fr/hfr/VideoSon/HiFi-HomeCinema/unique-haute-definition-sujet_141366_1.htm 60Hz, 59.94Hz, 29.97Hz, 24Hz, 23.976Hz are officials. Maybe a good way to deal with these frequencies is to present by default the "simplified" one. That will be OK 95% of the time. And for the "advanced" users add a checkbox "Display all frequencies" to display them all. What do you think ?
Review of attachment 324170 [details] [review]: looks good
Comment on attachment 324030 [details] [review] rr: Also export the frequency as a floating point number Committed and version bumped.
Any problems or concerns with the new refresh rate drop-down should be filed as new bugs. Attachment 324124 [details] pushed as 3814c9b - display: Add a way to specify the monitor refresh rate Attachment 324170 [details] pushed as 529b29c - display: Remove duplicate non-ATSC/NTSC rates from the list
I opened a bug report, as you ask, while it's still fresh :) https://bugzilla.gnome.org/show_bug.cgi?id=763819 And again Bastien, thank you very much for fixing this long standing issue !
As I said there is something wrong with the new feature : https://bugzilla.gnome.org/show_bug.cgi?id=763819#c13 Thanks !
*** Bug 770690 has been marked as a duplicate of this bug. ***