Announcement

Collapse
No announcement yet.

Fedora 20 Will Be Released Next Week

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Bucic View Post
    Technically I don't give a damn. Excuse my tone but IMO it's perfectly adequate to such attitude. Not yours, the maintainer's. I've reported the bug on Fedora's bugzilla, so if I have selected the wrong component a moderator (?) should change it, not ignore a bug that can damage hardware.

    Firmware? Bull. How many manhours does it take to implement a [Load_Cycle_Count delta > 5/min => disable power-saving mode] mechanism?

    Thanks for the hdparm tip. Your single post has been more helpful than the maintainers comments on the bug.
    No and I agree that the maintainer should've moved it to the proper category, but depending on the component's policy there may not be anything they can do. By that I mean, its the firmware's fault-- yell at the manufacturer. In the kernel you can post patches for Hardware Quirks, to compensate for buggy or inaccurate hardware (the laptop I am writing this from requires one such hardware quirk patch otherwise the backlight doesnt function correctly). But userspace... Maybe they wont accept hardware quirk patches, who knows.

    What it DOES come down to though is the firmware's fault. Linux adhere's to standards by default, so if the standard says XYZ then Linux assumes that anything claiming to be standards-complient will do XYZ, anything that breaks those assumptions is at fault. The one big exclusion to that I can think of is you can tell the kernel to report something other than Linux for ACPI, incase the hardware does one thing for Windows and another for Linux, and the Linux path is buggy.

    Comment


    • #17
      Originally posted by Ericg View Post
      The post by Adam is: http://phoronix.com/forums/showthrea...068#post379068

      But keep in mind his wording is "I dont believe" and F20 is already shipping a Xorg 1.15 snapshot isnt it?
      No. It includes xorg-x11-server-1.14.4. I don't think the graphics maintainers usually plan on major X or mesa version bumps within releases.

      Originally posted by Ericg View Post
      Or they may selectively pull in the DRI3 and Present changes. Only time will tell right now
      Backporting bugfixes is certainly something that happens, where it's practically possible and important enough to justify the time spent. Is there a clear bug report for whatever it is Bucic wants backported filed in bugzilla.redhat.com ?

      Comment


      • #18
        Originally posted by AdamW View Post
        No. It includes xorg-x11-server-1.14.4. I don't think the graphics maintainers usually plan on major X or mesa version bumps within releases.



        Backporting bugfixes is certainly something that happens, where it's practically possible and important enough to justify the time spent. Is there a clear bug report for whatever it is Bucic wants backported filed in bugzilla.redhat.com ?
        Bucic, and as a Sandy Bridge owner-- so do I, want the tearing fixed that occurs on Intel GPU's since the move to the Intel HD core. In order TO fix the tearing Fedora would have to backport all of the Present and DRI3 bits of both Mesa and Xorg 1.15, which honestly its really annoying that it didn't happen anyway because at the Xorg 1.15 Release Schedule planning meeting at XDC earlier this year the Fedora 20 release plan was specifically used as a reference point as to when Xorg 1.15 would have to be released by to get it into the F20 Beta in time.

        There's clutter and GTK environment variable workarounds available, but they dont work all the time to actually prevent the tearing that occurs.

        Bug Report: https://bugzilla.redhat.com/show_bug.cgi?id=977391

        Comment


        • #19
          Originally posted by Bucic View Post
          Well, at least RH has a community monkey I'm sure the Mutter guys have no QA monkeys.

          It would all mean that the only hope to get the tearing fixed is to report a bug against the Gnome-related issue on fedora's bugzilla. The only problem is my experience with such a scenario:
          Bug 977391 - Gnome Shell tearing on Sandy Bridge
          First, clueless about what is wrong with the animations, then - fails to connect the dots regarding the well known issue with mutter vs intel causing this, to finally abandon the bug altogether.
          Tracked down the source:

          Keith Packard-- Future Directions Of The X Window System -- Linux.conf.au 2013
          http://www.youtube.com/watch?v=u8gqB301PbY&html5=1

          Jump to the following timestamps:
          1) 04:20
          2) 21:00-22:00
          3) 48:10

          Tearing on Sandy Bridge, Ivy Bridge (not sure if Haswell) is caused by hardware engineers removing a feature related to Scan-Out during the jump to the "Intel HD" graphics core. The only REAL solution is DRI3 + Present

          Comment


          • #20
            Originally posted by Ericg View Post
            But userspace... Maybe they wont accept hardware quirk patches, who knows.
            Could you clarify, who do you mean by 'userspace' with regard to the case we discuss?

            Originally posted by Ericg View Post
            What it DOES come down to though is the firmware's fault. Linux adhere's to standards by default, so if the standard says XYZ then Linux assumes that anything claiming to be standards-complient will do XYZ, anything that breaks those assumptions is at fault. The one big exclusion to that I can think of is you can tell the kernel to report something other than Linux for ACPI, incase the hardware does one thing for Windows and another for Linux, and the Linux path is buggy.
            I get that, I do. But at the same time there's something like fail-safe mechanisms. In our case such mechanism would cost squat. The reason it's not implemented for the 'click-clack' is not high manhours but, most probably, that nobody gives a rats buttocks. As I see this is an issue that's known for years and across distributions
            http://forum.linuxmint.com/viewtopic.php?f=49&t=94336
            askubuntu.com/questions/82803/hard-drive-clicking-noise-on-acer-ao722
            askubuntu.com/questions/60078/laptops-hard-drive-doesnt-really-spin-down/

            Back to the fail-safe. Call it overly dramatic, but fail-safe is what actually kept alive anybody who took flight more than 50 times. What I'm saying here is that non-standard implementations happen and WILL happen. Linux devs can't just ignore the reality. Just watch some Matthew Garrett's presentations on UEFI.





            Originally posted by AdamW View Post
            Is there a clear bug report for whatever it is Bucic wants backported filed in bugzilla.redhat.com ?
            Reported both on gnome's and redhat's bugzilla (just as a reminder):
            Bug 977391 - Gnome Shell tearing ... - bugzilla.redhat.com
            Bug 711028 - Tearing on Intel GPU - the CLUTTER_PAINT workaround

            Please note that my hardware is not Sandy Bridge. I've misidentified my hardware. Since I was not getting any input on redhat's bugzilla I've updated only the bug description on bugzilla.gnome.org
            Also please do report back if you learn of anything new on the subject.

            Originally posted by Ericg View Post
            Bucic, and as a Sandy Bridge owner-- so do I, want the tearing fixed that occurs on Intel GPU's since the move to the Intel HD core. In order TO fix the tearing Fedora would have to backport all of the Present and DRI3 bits of both Mesa and Xorg 1.15, which honestly its really annoying that it didn't happen anyway because at the Xorg 1.15 Release Schedule planning meeting at XDC earlier this year the Fedora 20 release plan was specifically used as a reference point as to when Xorg 1.15 would have to be released by to get it into the F20 Beta in time.

            There's clutter and GTK environment variable workarounds available, but they dont work all the time to actually prevent the tearing that occurs.

            Bug Report: https://bugzilla.redhat.com/show_bug.cgi?id=977391
            I know the particular bug report and the workaround now. Isn't it grand? At least two generations of Intel graphics affected by a bug that is present for 12 months? This kind of stuff is exactly what makes me look like a damn fool when I advocate for Linux.

            On the workaround. It's exactly that, a workaround. It doesn't restore the proper performance and it isn't conservative on resources, since it redraws entire image every time.

            Comment


            • #21
              Originally posted by Ericg View Post
              Tearing on Sandy Bridge, Ivy Bridge (not sure if Haswell) is caused by hardware engineers removing a feature related to Scan-Out during the jump to the "Intel HD" graphics core. The only REAL solution is DRI3 + Present
              Removing the feature from where? The intel drivers or hardware?

              My hardware is GM45 so Gen4, BTW.

              Thanks for the video presentation!

              Comment


              • #22
                bucic: maybe I can give you a slightly different perspective. we do care, we really do, about all the real problems people run into. I haven't met anyone working on F/OSS who really didn't care about users hitting problems, even the most elitist of devs.

                But here's the thing. I've worked for a tiny tiny Linux company (Mandriva) and a huge one (Red Hat), and even at RH...we never have anywhere near enough people for everything. Nowhere even close.

                AFAIK, there are three people working full time on graphics development for Red Hat - that's both Fedora and RHEL. Three people. They're responsible for all of this - every generation of NVIDIA, Intel and Radeon hardware for every release of Fedora and RHEL. They're just never going to get to everything, it is human nature. The Intel driver has, I think, the most resources dedicated to its upstream development out of the three, by Intel and by other companies, but it's still really not that well-resourced.

                Every F/OSS dev I've ever met has been super dedicated and driven and worked well beyond the call of duty or their set working hours or anything like that. But equally, they have all been _insanely_ busy. RH isn't particularly stingy with development resources, but it's just not economically feasible for RH to throw a dozen or two developers at the graphics stack, which is what it would really need.

                Comment


                • #23
                  Originally posted by Bucic View Post
                  Removing the feature from where? The intel drivers or hardware?

                  My hardware is GM45 so Gen4, BTW.

                  Thanks for the video presentation!
                  Feature got removed from hardware. It was called like 'TearFree Mode" or "No-Tear Mode" something like that. I THINK anything Pre-Sandy Bridge had it, it def wasn't there in Sandy Bridge though. Which makes you hitting a tearing bug interesting since DRI2 + TearFree Mode + Compositing.... shouldn't be tearing on Pre-Sandy Bridge

                  Comment


                  • #24
                    Originally posted by AdamW View Post
                    bucic: maybe I can give you a slightly different perspective. we do care, we really do, about all the real problems people run into. I haven't met anyone working on F/OSS who really didn't care about users hitting problems, even the most elitist of devs.

                    But here's the thing. I've worked for a tiny tiny Linux company (Mandriva) and a huge one (Red Hat), and even at RH...we never have anywhere near enough people for everything. Nowhere even close.

                    AFAIK, there are three people working full time on graphics development for Red Hat - that's both Fedora and RHEL. Three people. They're responsible for all of this - every generation of NVIDIA, Intel and Radeon hardware for every release of Fedora and RHEL. They're just never going to get to everything, it is human nature. The Intel driver has, I think, the most resources dedicated to its upstream development out of the three, by Intel and by other companies, but it's still really not that well-resourced.

                    Every F/OSS dev I've ever met has been super dedicated and driven and worked well beyond the call of duty or their set working hours or anything like that. But equally, they have all been _insanely_ busy. RH isn't particularly stingy with development resources, but it's just not economically feasible for RH to throw a dozen or two developers at the graphics stack, which is what it would really need.
                    I know this was directed to Bucic, but I want to just pop in briefly. I don't think anyone here is implying that Red Hat as awhole doesn't care or isn't putting forth effort, Red Hat's done a lot of great work with the Linux Ecosystem and the work is appreciated, and we are aware that the Devs are working their asses off getting as many things done as they can. Its just extra annoying to me as a user, and as enthusiast, that this work didn't land for Fedora 20 and doesnt seem like it WILL-- especially given that during the release planning of Xorg 1.15 the Fedora 20 schedule was the ONLY distro-related reference point used, and I'm fairly certain that Ajax himself was in the room.

                    What makes it even more annoying is that at this rate, DRI3 and Present-- the "stopgaps" for Xorg to make it more Wayland-like wont hit Fedora now.. Until the move over to Wayland occurs (currently targeted at F21 according to the Feature Wiki) so the amount of people on the Fedora side who can benefit from the work that Keith has been doing gets limited, as well as those bugs remaining unfixed for another six months.

                    Comment


                    • #25
                      Originally posted by Ericg View Post
                      I know this was directed to Bucic, but I want to just pop in briefly. I don't think anyone here is implying that Red Hat as awhole doesn't care or isn't putting forth effort, Red Hat's done a lot of great work with the Linux Ecosystem and the work is appreciated, and we are aware that the Devs are working their asses off getting as many things done as they can. Its just extra annoying to me as a user, and as enthusiast, that this work didn't land for Fedora 20 and doesnt seem like it WILL-- especially given that during the release planning of Xorg 1.15 the Fedora 20 schedule was the ONLY distro-related reference point used, and I'm fairly certain that Ajax himself was in the room.

                      What makes it even more annoying is that at this rate, DRI3 and Present-- the "stopgaps" for Xorg to make it more Wayland-like wont hit Fedora now.. Until the move over to Wayland occurs (currently targeted at F21 according to the Feature Wiki) so the amount of people on the Fedora side who can benefit from the work that Keith has been doing gets limited, as well as those bugs remaining unfixed for another six months.
                      I should emphasize I haven't specifically talked to ajax about this, I'm just going on past experience. You know more about this discussion you're referring to than I do - I wasn't there and don't know the first thing about it!

                      If I remember to, next time I'm talking to ajax I'll ask him about this stuff and if they have any plans for F20, or if it's F21 stuff at this point.

                      (I'm running F21 now, BTW. Doesn't seem to have any hideous explosion bugs in it yet. Come on in, the water's lukewarm and I haven't seen any sharks yet!)

                      Comment


                      • #26
                        Originally posted by Ericg View Post
                        Feature got removed from hardware. It was called like 'TearFree Mode" or "No-Tear Mode" something like that. I THINK anything Pre-Sandy Bridge had it, it def wasn't there in Sandy Bridge though. Which makes you hitting a tearing bug interesting since DRI2 + TearFree Mode + Compositing.... shouldn't be tearing on Pre-Sandy Bridge
                        Yeah, that part sounds like the most interesting part to me as well. I wonder if there is some command or log you can inspect to find out for sure if your specific system includes this hardware feature or not?

                        Comment


                        • #27
                          Originally posted by Ericg View Post
                          Feature got removed from hardware. It was called like 'TearFree Mode" or "No-Tear Mode" something like that. I THINK anything Pre-Sandy Bridge had it, it def wasn't there in Sandy Bridge though. Which makes you hitting a tearing bug interesting since DRI2 + TearFree Mode + Compositing.... shouldn't be tearing on Pre-Sandy Bridge
                          Yes, I have a pre-Sandy Bridge chipset, that's why the explanation with the removal of hardware feature seemed fishy to me! I can boot F18 official livecd right now and it won't tear. It will start as soon as I install it and update it. It's all there in my bug reports.

                          Comment


                          • #28
                            Originally posted by AdamW View Post
                            I should emphasize I haven't specifically talked to ajax about this, I'm just going on past experience. You know more about this discussion you're referring to than I do - I wasn't there and don't know the first thing about it!

                            If I remember to, next time I'm talking to ajax I'll ask him about this stuff and if they have any plans for F20, or if it's F21 stuff at this point.

                            (I'm running F21 now, BTW. Doesn't seem to have any hideous explosion bugs in it yet. Come on in, the water's lukewarm and I haven't seen any sharks yet!)
                            Xorg Foundation put up a video copy of the release schedule meeting, its only 10 minutes long: http://www.youtube.com/watch?v=jdd0zFQCU_I&html5=1

                            Isn't that Ajax's voice around the 5 minute mark saying that he just wanted a release done by the Beta release and after that he didn't care? Obviously, things can get changed things come up, understandably. That talk is just the only reference-able discussion I've seen or heard so that's all we've got to go on unless someone else can chime in with a link to a mailing list or the likes saying "The plans been changed."

                            Xorg 1.15 Release Candidate was: November 1, 2013
                            Fedora 20 Beta Release date was: November 11, 2013

                            Comment


                            • #29
                              Are menu icons and context menu icons still missing in F20? Gconf-editor menus_have_icons/buttons_have_icons options don't work.

                              Comment


                              • #30
                                Did update from F19 to F20 wth fedup today. Had some problems, mainly had to pull newer fedup version from updates-testing in order to do that. Such a blunder from dev side! After that fedup wasn't all that smooth, had to manually yum distro-sync to get some bits right and even after that remove and reinstall LibreOffice so it would use fc20 packages. So not so smooth... but hey at least the system works perfectly post-update those small glitches aside, which has never been the case for me with Ubuntu.

                                System itself is nearly flawless (running GNOME 3.10). Some plugins from GNOME 3.8 weren't compatible, luckily simple visit to extensions.gnome.org and getting new ones manually fixed that. Evolution also has a glitch in menus, the titles are invisible until hovering mouse over them. Well, at least then they stay visible until closing. Oddly the new quicksettings menu lacks bluetooth options, otherwise I find it superior to competition. Also had to purge Rhythmbox databases and settings, something caused one core to be used fully before doing that.

                                Those few glitches aside (those were all) smooth sailing. Random stuttering in compositing and tearing in video playback which occasionally happened in F19 are now gone. I really like the new titlebar system, so much more screen estate with applications following that HIG. Also a huge boon is that taskbar now supports right-clicking to minimize/maximize/close applications from there. The new Software application is already IMHO much better than Ubuntu's software centre. So much cleaner design. Might also play a role that Fedora has cleaner repositories. No random books or pay-software to be seen.

                                I'd say overall better than F19 was. I obviously had some post-upgrade issues there as well, moving from F18 to F19-beta to F19. Now that I think about it, this might be the longest streak I've ever stayed on one distro. Small nuisances and random problems I get in every other distro just don't exist here. Definitely recommending.

                                Comment

                                Working...
                                X