Fedora 20 Will Be Released Next Week

[Bucic]

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? So it may end up shipping regardless. Or they may selectively pull in the DRI3 and Present changes. Only time will tell right now

Hold on, you were IN that thread, Bucic -_-

No, Fedora 20 is shipping Xorg 1.14.
I was, but I thought you speak of someone else by the name of Adam or that you have some info on the Adam's credibility.

Distrowatch is great for getting info on versions of core packages, though I agree it's a nice thing to have on a distribution's website.

Fedora packadges

https://admin.fedoraproject.org/updates/FEDORA-2013-22028/xorg-x11-server-1.14.4-5.fc20?_csrf_token=2a059e230b5e7722d6e612ec415457102686f259

http://phoronix.com/forums/showthread.php?90758-Fedora-20-Will-Ship-With-The-Linux-3-11-Kernel&p=379002#post379002

https://fedoraproject.org/wiki/Releases/20/ChangeSet

[Ericg]

or that you have some info on the Adam's credibility.

Well as far as HIS credibility... He "works for Red Hat as the Fedora QA Community Monkey." lol

https://fedoraproject.org/wiki/User:Adamwill

[Bucic]

Well as far as HIS credibility... He "works for Red Hat as the Fedora QA Community Monkey." lol

https://fedoraproject.org/wiki/User:Adamwill

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.

Somewhat similar flow
Bug 979551 - Disk produces regular clicking sound
"this is just userspace" grinding your HDD mechanisms, I heard. Go figure.

[Ericg]

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.

(I have a response to this, but im currently tracking down the source)

Bug 979551 - Disk produces regular clicking sound [/URL]
"this is just userspace" grinding your HDD mechanisms, I heard. Go figure.

Well... Technically is probably buggy hard drive firmware that userspace is assuming is accurate. Time-to-spindown, at least in my experience, is measured in minutes. Like 5mniutes, 10 minutes and then it will spin down to conserve power. But in that bug the firmware is reporting a spin down time of (if we assume that its in seconds, and im not sure it is) 2 minutes and 43seconds.... Which is just odd. Its like when you see marker at a train station and its marked as platform "9 3/4" ( ) its just... wrong.

So userspace is taking the firmware literally, the drive is spinning down. The heads are parking, hence the initial click. The heads spinback up when data is needed (which for a game installed on the hard drive, that would be... constantly) thats the second click. Firmware shuts down the drive again, click, powers it back up, click. Etc. TLP is trying to force a new value to the firmware, but the drive isnt accepting it. The safest thing for the user to do would be to turn off power-saving mode on the drive which can normally be done through hdparm, because obviously the firmware of the drive isn't responsible enough to handle it

[Bucic]

(I have a response to this, but im currently tracking down the source)



Well... Technically is probably buggy hard drive firmware that userspace is assuming is accurate. Time-to-spindown, at least in my experience, is measured in minutes. Like 5mniutes, 10 minutes and then it will spin down to conserve power. But in that bug the firmware is reporting a spin down time of (if we assume that its in seconds, and im not sure it is) 2 minutes and 43seconds.... Which is just odd. Its like when you see marker at a train station and its marked as platform "9 3/4" ( ) its just... wrong.

So userspace is taking the firmware literally, the drive is spinning down. The heads are parking, hence the initial click. The heads spinback up when data is needed (which for a game installed on the hard drive, that would be... constantly) thats the second click. Firmware shuts down the drive again, click, powers it back up, click. Etc. TLP is trying to force a new value to the firmware, but the drive isnt accepting it. The safest thing for the user to do would be to turn off power-saving mode on the drive which can normally be done through hdparm, because obviously the firmware of the drive isn't responsible enough to handle it

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.

[Ericg]

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.

[AdamW]

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.

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 ?

[Ericg]

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

[Ericg]

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

[Bucic]

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?

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.

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.

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.