Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Operating Systems GNOME Ubuntu Linux Technology

Ubuntu Works With GNOME To Improve HiDPI Support On Linux Desktop (omgubuntu.co.uk) 85

An anonymous reader shares an article: Canonical is playing host to a 'fractional scaling hackfest' in its Taipei offices this week. Both GNOME developers and Ubuntu developers are in attendance, ready to wrestle with the aim: improve GNOME HiDPI support. Ubuntu's Unity desktop (I'm told, anyhow) plays fairly nice with high DPI monitors because the shell supports fractional scaling (though most apps, I believe, do not). Furthermore, users can tweak some high DPI settings to better suit their display(s). GNOME Shell also supports HiDPI monitors, but has, until now, been a little less flexible about it. "Currently, we only allow to scale windows by integral factors (typically 2). This proves somewhat limiting as there are many systems that are just in between the dpi ranges that are good for scale factor 2, or unscaled," the hackfest page explains.
This discussion has been archived. No new comments can be posted.

Ubuntu Works With GNOME To Improve HiDPI Support On Linux Desktop

Comments Filter:
  • It's good news that they are moving to address things like this that are standard in other operating systems and to hopefully standardize on a way of doing it so we don't end up with everybody coming up with their own incompatible way of doing it. The issue will really come down to application support though, with so many different application frameworks on Linux they all need to support it, do so in the same way as GNOME and also then make sure that applications are written to support it. Application suppo

    • Unity already works fine with HiDPI, but Gnome 3 not so much. As the later will be the default DE, Canonical is working together with them. Apps are mixed, depending on the framework and version.
      • by lucm ( 889690 )

        I use Fedora and it works perfectly well with HiDPI. Had for a long time. The only thing that doesn't work well with it is LibreOffice, but of course a lot of things don't work well when it comes to LibreOffice.

        • by Ed Avis ( 5917 )
          I've found Fedora a bit unstable on a 4k display. It looks good enough if you set the 2x scaling (although Libreoffice requires some additional mucking around with X server dpi settings, and I think Firefox needs its own config tweak too). However, with Noveau drivers and an NVS 510 card, the machine would hang after a while, particularly when using Firefox. In the end I had to go back to 1920x1080 resolution to make the system stable. That's just one anecdote, but it shows there is some work to be done
    • by dbIII ( 701233 )

      It will be a long time for it to become commonly available

      It is commonly available - it just wasn't in Gnome3.
      Enlightenment had it many years ago and pretty well everything else did it not long after.

      • How does Enlightenment handle HiDPI UI scaling with GTK applications for example?
        • by dbIII ( 701233 )
          It has it's own toolkit for it's own applications instead of using broken Gnome3 applications.
          For other stuff there's qt, gtk2 and many other things.

          Seriously guys, I remember reading about this stuff on a mailing list around 2000 FFS! A lot of people were paying attention to it before the Gnome3 people even started programming!
          • Yes this is what I mean, there's no standard way. Everybody comes up with their own way, so if you look at Fedora you can only do integer scaling even though libraries like EFL support floating point scaling for example. Is there a specification for a standard way that all these different windowing kits and libraries handle dpi unaware, dpi system aware and multi-screen dpi aware? Otherwise everybody just goes off and does their own thing and you end up with systems that people expect to work together that
            • by dbIII ( 701233 )
              Here is a bit of a summary:
              https://wiki.archlinux.org/ind... [archlinux.org]
            • by dbIII ( 701233 )

              Yes this is what I mean, there's no standard way

              Oh yes there is.
              Applications such as chrome get the value for X instead of having hard coded sizes like gnome3 does. (https://wiki.archlinux.org/index.php/HiDPI#X_Server)

              • Applications can get the DPI settings directly from X.
                It's what that value is for FFS.
                • Applications can get the DPI settings directly from X. It's what that value is for FFS.

                  DPI is only one part of it, the important other part is scaling. Do all display servers, WMs and frameworks have a common way in which DPI and scaling should be interpreted for dpi-unaware and dpi-aware applications as well as how this is dealt with in multi-monitor setups?

                  IMO the way Windows handles DPI and scaling in multi-monitor setups is pretty crappy.

                  • by dbIII ( 701233 )

                    dpi-unaware and dpi-aware applications

                    With the greatest possible respect, what excuse is there for a graphical application designed to be used by anyone other than the original programmer to be dpi-unaware on any platform that can have more than one screen size or resolution?

                    • I don't know and I don't really care, the reality is many of them exist and are in use widely.
                    • by tepples ( 727027 )

                      The excuse is the failure of "anyone other than the original programmer" to have donated money to "the original programmer" earmarked toward improving support for oddball pixel densities.

                • That would be great, except for all the broken shit like GTK 3 that throws out the EDID-reported value and just blindly uses 96 DPI instead!

                  (I just installed Debian Stretch on a PC with a 27" 4k monitor, and I'm a kinda pissed off about this issue right now.)

  • by Lisandro ( 799651 ) on Tuesday June 06, 2017 @08:34PM (#54564645)

    GTK is still unable to properly scale bitmap icons, which means that some UI elements stay tiny while windows and fonts scale properly.

  • by MeNeXT ( 200840 ) on Tuesday June 06, 2017 @10:32PM (#54565281)

    Nice to hear that they are working on simplifying this.

    After setting 2:1 scaling in Gnome I found that my 1080p monitor was almost useless and while my 4K looked great everything was too large. So I used xrandr to set things to a more comfortable level by scaling the 1080p monitor by 2x2 and the 4K by 1.6x1.6 with the following xrandr commands which run at start up.

    xrandr --output DP-0 --pos 0x0 --scale 1.6x1.6
    xrandr --output HDMI-0 --mode 1920x1080 --pos 6144x0 --scale 2x2

    I'm using Fedora 25 but this should work for other Linux versions too. The tricky part is finding the right setting for your comfort level. So far I haven't found any issues with it. You can customize the resolution for each user if you cared.

    • Was not aware we could set custom scaling ratios with xrandr, and keep playing with them based on varying hardware.

      Only helpful post in this thread, thanks!

      • by MeNeXT ( 200840 )

        The issue is that you first need to set
        $ gsettings set org.gnome.desktop.interface scaling-factor 2

        then check xrandr for your card/monitor support..

        Here is what it looks like when set;
        $ xrandr
        Screen 0: minimum 8 x 8, current 9984 x 3456, maximum 32767 x 32767
        DVI-D-0 disconnected (normal left inverted right x axis y axis)
        DP-0 connected primary 6144x3456+0+0 (normal left inverted right x axis y axis) 607mm x 345mm
        3840x2160 60.00*+ 30.00
        2560x1440 59.95

    • by AmiMoJo ( 196126 )

      The best solution is to get a monitor with a physical size and resolution that is suited to 2x scaling.

      The old standard for computer displays was 96 DPI. A 24" monitor at 1080p is around that, so to get perfect 2x scaling you really want a 24" 4k monitor. All these larger 27" and 32" 4k monitors are just awkward for scaling, unless you plan is to sit really far back from them.

      If you want an actual 27" monitor, you need 5k. Those monitors are really expensive but starting to come down.

      • by MeNeXT ( 200840 )

        All these larger 27" and 32" 4k monitors are just awkward for scaling, unless you plan is to sit really far back from them.

        If you want an actual 27" monitor, you need 5k. Those monitors are really expensive but starting to come down.

        My 28" 4K monitor with a gnome scaling factor of 2 and xrandr scale factor of 1.5x1.5 or 1.6x1.6 gives identical results as my iMac 5K setup. Since Gnome factors all screens the same you need to scale regular displays at 2x2 in xrandr for dual monitor support. Again my dual monitor Fedora setup looks identical to my iMac dual monitor setup.

        It is very workable as a desktop. Some applications may need fine tuning. On Fedora 25 I've had a very satisfying experience so far. I've been running it for at least 2 w

  • by caseih ( 160668 ) on Tuesday June 06, 2017 @11:19PM (#54565521)

    Is a display system that is resolution independent still a distant dream? Seems like this HiDPI stuff is just a hack, though I'll agree it's not the worst hack I've ever seen.

    Years ago we thought eventually we'd have desktop where everything was displayed in actual units like centimetres or points, and since everything was to be scalable, you could zoom it anyway you want and it would remain nice and sharp. Although we have scalable fonts that HiDPI relies on, seems like we gave up on vector graphics for drawing with (too slow?), and now we just bitmap scale the whole GUI (except the fonts). Is there no better way?

  • GNOME had this (Score:5, Informative)

    by Zan Lynx ( 87672 ) on Tuesday June 06, 2017 @11:33PM (#54565597) Homepage

    They had this in 2005. It was called DPI. It scaled really well. Then some IDIOTS decided it should be force set to 92.

    • Re:GNOME had this (Score:4, Informative)

      by jbernardo ( 1014507 ) on Wednesday June 07, 2017 @12:40AM (#54565873)

      This was broken on purpose on gtk+ by a gnome developer called Matthias Clasen.

      You can see a description of this in this reddit discussion, and the bug and the amazing answers by Mr. Clasen are here.

      It did not only break gnome support of HiDPI, but also broke any app using gtk+, like Firefox or libreoffice..

      • Re:GNOME had this (Score:5, Informative)

        by jbernardo ( 1014507 ) on Wednesday June 07, 2017 @12:51AM (#54565945)

        Doh, it seems that the URLs didn't survive the submit, so here they are again:

        - reddit comments on gtk+ breaking HiDPI - https://www.reddit.com/r/linux/comments/6cf1dq/what_was_the_most_baffling_problem_in_linux_youve/dhuhuk4/ [reddit.com]

        -bugzilla report - https://bugzilla.gnome.org/show_bug.cgi?id=757142 [gnome.org]

        • That entire discussion is just baffling. Did anyone ever explain the rationale behind the decision to hardcode a DPI setting instead of getting it from X?

          • Re: GNOME had this (Score:4, Interesting)

            by jbernardo ( 1014507 ) on Wednesday June 07, 2017 @04:45AM (#54566575)

            The only explanation is in the commit - https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f [gnome.org]

            Instead of testing to see if the DPI values were non-zero, the developer just decided to force 96 DPI fully ignoring the detected values.

            I won't comment on the developer's abilities, I think that commit speaks for itself

            .

          • by Anonymous Coward

            dpi_double = 96.0;

            Anyone doing that in place of code that already asks x for the correct valves is a bad actor. Magic numbers are bad. m'kay.

            To "won't fix" when it's pointed out as a regression.... maybe breaking x support ahead of a shift to wayland?

            • To "won't fix" when it's pointed out as a regression.... maybe breaking x support ahead of a shift to wayland?

              Oh, well that's a much better accusation of nefarious motivation than being paid off by Microsoft.

          • by AmiMoJo ( 196126 )

            Did anyone ever explain the rationale behind the decision to hardcode a DPI setting instead of getting it from X?

            Or why the submitted patch to undo the regression wasn't accepted.

        • by amorsen ( 7485 )

          The "force 96" code looks like it only activates if X doesn't know the DPI. This seems like a quite sensible proposal: If X doesn't know the DPI, then fix X.

          • by tepples ( 727027 )

            This seems like a quite sensible proposal: If X doesn't know the DPI, then fix X.

            With the implication being that if the chipset makers obstruct X from knowing the DPI, fix the chipset makers. Good luck with that.

            • by amorsen ( 7485 )

              If the Gnome code can calculate the DPI from the screen dimensions and the resolution, then so can X. Put the workaround where it belongs, in the X code where it only needs to be maintained once, rather than in each toolkit.

              • True, the actual density depends on the screen dimensions and pixel count. But an uncooperative chipset maker can hide the screen dimensions from X.

                In addition, effective density depends on the viewing distance. If the monitor is twice as far away, it takes twice as many pixels in each direction to make the same size image on the viewer's retina, giving it twice the effective density. This is why CSS defines the px unit as 1/2688 of the viewing distance, which represents a 96 dpi display at 28 inches, round

                • by amorsen ( 7485 )

                  Yes, plain-old-DPI is a fairly useless metric. But the whole premise is that Gnome should do magic when DPI isn't set in the X-server, invoking incantations until the right DPI suddenly appears in the wisps of smoke. Consensus on Slashdot is that the Gnome team are a bunch of ridiculous bastards for not being willing to do that.

                  Whereas that seems like the entirely correct solution to me -- if there has to be magic spells involved, put them in the X server, not in each toolkit. And if the magic incantations

  • Banging one's head repeatedly against the wall should be painful. And yet Canonical insists on doing it. When the decision was made to abandon Unity, they chose the inferior solution among the GNU/Linux desktops. Plasma 5 (KDE) is HiDPI-ready. But no, they stubbornly chose GNOME and now they have to throw resources and manpower to hack at the GNOME codebase to fix something that was already fixed in Plasma.

    They should have gone with Plasma which is IMHO much better.

    OK, I get that it's their project and thei

"Marriage is low down, but you spend the rest of your life paying for it." -- Baskins

Working...