In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too.
-- Rex
ah will the https://koji.fedoraproject.org/koji/buildinfo?buildID=707268 now be at least pushed to updates-testing which i am running for many months (in fact from my first Fedora 23 day)
that would have saved a lot of troubles for my co-worker with KDE5 in a IvyBrdige machine and after he had enough of windows of OpenGL applications randomly now redrwaing and so on he found out the following settings makes things dramatically beteter form him, especially when wine games are part of the game
Option "DRI" "3"
since we both have 100% identical hardware it took a while to find out the only difference was the intel driver *never* made it to any repo
the build *before* the linked one had crashes when play video with VLC while i reverted my positived karma because of that the following build had no issues
Am 20.02.2016 um 15:46 schrieb Rex Dieter:
In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too
On Sáb, 2016-02-20 at 08:46 -0600, Rex Dieter wrote:
In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
Yes , Ajax re-enable DRI3 again [1] maybe we should move this thread to devel ML.
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too.
-- Rex _______________________________________________ kde mailing list kde@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kde@lists.fedoraproject.or g
On Sat, Feb 20, 2016 at 3:46 PM, Rex Dieter rdieter@math.unl.edu wrote:
In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too.
As I wanted to try Vulkan (just for curiosity) right after the announcement, I'm on the DRI3 enabled Intel driver for a few days already and I don't see any issues.
Jaroslav
-- Rex _______________________________________________ kde mailing list kde@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kde@lists.fedoraproject.org
Jaroslav Reznik wrote:
On Sat, Feb 20, 2016 at 3:46 PM, Rex Dieter rdieter@math.unl.edu wrote:
In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too.
As I wanted to try Vulkan (just for curiosity) right after the announcement, I'm on the DRI3 enabled Intel driver for a few days already and I don't see any issues.
Jaroslav
-- Rex _______________________________________________ kde mailing list kde@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kde@lists.fedoraproject.org
I've seen lots of kde lockups, and switching between multi/single monitors on wake seems a lot worse (it was already bad)
Just did it again.
Came back from lunch, screen is locked. screen lock will not accept a password - can't seem to put focus on the password entry field.
Switch to VT, killall Xorg. Then login again. Now laptop screen is completely off, external monitor is OK.
On 23.02.2016 19:10, Neal Becker wrote:
Just did it again.
Came back from lunch, screen is locked. screen lock will not accept a password - can't seem to put focus on the password entry field.
Switch to VT, killall Xorg. Then login again. Now laptop screen is completely off, external monitor is OK.
I had all those problems too, but with xorg-x11-drv-intel-2.99.917-21.20160119.fc24.x86_64 things are looking good.
FWIW, killing kscreenlocker-kgreet (and occasionally also killing and restarting kwin_x11 and plasmashell) was sufficient to recover the system, without losing any work.
The one thing which still causes trouble is switching from laptop screen to two external monitors. But I suspect this is Qt still not having all its multiscreen issues sorted out.
kde mailing list kde@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kde@lists.fedoraproject.org
Sandro Mani wrote:
On 23.02.2016 19:10, Neal Becker wrote:
Just did it again.
Came back from lunch, screen is locked. screen lock will not accept a password - can't seem to put focus on the password entry field.
Switch to VT, killall Xorg. Then login again. Now laptop screen is completely off, external monitor is OK.
I had all those problems too, but with xorg-x11-drv-intel-2.99.917-21.20160119.fc24.x86_64 things are looking good.
Where did you find that?? There's no 20160119 in this list:
sudo dnf --enablerepo=rawhide info xorg-x11-drv-intel --show Last metadata expiration check performed 0:05:45 ago on Tue Feb 23 13:31:20 2016. Installed Packages Name : xorg-x11-drv-intel Arch : x86_64 Epoch : 0 Version : 2.99.917 Release : 19.20151206.fc23 Size : 1.9 M Repo : @System From repo : updates-testing Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description : X.Org X11 Intel video driver.
Available Packages Name : xorg-x11-drv-intel Arch : i686 Epoch : 0 Version : 2.99.917 Release : 16.20150729.fc23 Size : 695 k Repo : fedora Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description : X.Org X11 Intel video driver.
Name : xorg-x11-drv-intel Arch : x86_64 Epoch : 0 Version : 2.99.917 Release : 16.20150729.fc23 Size : 677 k Repo : fedora Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description : X.Org X11 Intel video driver.
Name : xorg-x11-drv-intel Arch : i686 Epoch : 0 Version : 2.99.917 Release : 19.20151206.fc23 Size : 697 k Repo : updates Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description : X.Org X11 Intel video driver.
Name : xorg-x11-drv-intel Arch : x86_64 Epoch : 0 Version : 2.99.917 Release : 19.20151206.fc23 Size : 1.9 M Repo : @System From repo : updates-testing Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description : X.Org X11 Intel video driver.
Name : xorg-x11-drv-intel Arch : x86_64 Epoch : 0 Version : 2.99.917 Release : 19.20151206.fc23 Size : 679 k Repo : updates Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description : X.Org X11 Intel video driver.
Name : xorg-x11-drv-intel Arch : i686 Epoch : 0 Version : 2.99.917 Release : 19.20151206.fc24 Size : 697 k Repo : rawhide Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description : X.Org X11 Intel video driver.
Name : xorg-x11-drv-intel Arch : x86_64 Epoch : 0 Version : 2.99.917 Release : 19.20151206.fc24 Size : 679 k Repo : rawhide Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description : X.Org X11 Intel video driver.
On 23.02.2016 19:39, Neal Becker wrote:
Sandro Mani wrote:
I had all those problems too, but with xorg-x11-drv-intel-2.99.917-21.20160119.fc24.x86_64 things are looking good.
Where did you find that?? There's no 20160119 in this list:
Hmm, old cache?
Name : xorg-x11-drv-intel Arch : i686 Epoch : 0 Version : 2.99.917 Release : 21.20160119.fc24 Size : 698 k Repo : rawhide Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description : X.Org X11 Intel video driver.
Otherwise, koji always has the latest stuff:
Am 23.02.2016 um 19:39 schrieb Neal Becker:
Sandro Mani wrote:
I had all those problems too, but with xorg-x11-drv-intel-2.99.917-21.20160119.fc24.x86_64 things are looking good.
Where did you find that?? There's no 20160119 in this list:
sudo dnf --enablerepo=rawhide info xorg-x11-drv-intel --show
there where you find *all* builds https://koji.fedoraproject.org/koji/packageinfo?packageID=7794
Sandro Mani wrote:
On 23.02.2016 19:10, Neal Becker wrote:
Just did it again.
Came back from lunch, screen is locked. screen lock will not accept a password - can't seem to put focus on the password entry field.
Switch to VT, killall Xorg. Then login again. Now laptop screen is completely off, external monitor is OK.
I had all those problems too, but with xorg-x11-drv-intel-2.99.917-21.20160119.fc24.x86_64 things are looking good.
FWIW, killing kscreenlocker-kgreet (and occasionally also killing and restarting kwin_x11 and plasmashell) was sufficient to recover the system, without losing any work.
Yes, this is happening a LOT. killall -TERM kscreenlocker-kgreet, killall - s SISEGV plasmashell, AND each time google chrome is locked and needs to be restarted as well. No idea about that one.
What do Intel maintainers want to achieve by intentionally breaking system of so many people?
Am 02.03.2016 um 15:31 schrieb Sudhir Khanger:
What do Intel maintainers want to achieve by intentionally breaking system of so many people?
really? which systems?
aksing because we maintain 4 KDE workstations with Intel graphics and enable DRI3 in fact fixed a lot of terrible graphics problems after the KDE5 switch of F22
frankly we would have saved a lot of anger and time if that package would not had stalled on koji forever
My system is broken. It's a Thinkpad T420s with Intel 4400 integrated graphic card.
On Wednesday 02 of March 2016 16:20:47 Sudhir Khanger wrote:
My system is broken. It's a Thinkpad T420s with Intel 4400 integrated graphic card.
Can you please try to remove the -intel driver and try the modesetting one?
Debian recently decided to deprecate the -intel in favour of the generic one (which should work on recent models): http://unix.stackexchange.com/questions/259733/this-driver-is-deprecated-in-... Worth to try.
Ciao
Luigi Toscano wrote:
On Wednesday 02 of March 2016 16:20:47 Sudhir Khanger wrote:
My system is broken. It's a Thinkpad T420s with Intel 4400 integrated graphic card.
Can you please try to remove the -intel driver and try the modesetting one?
Debian recently decided to deprecate the -intel in favour of the generic one (which should work on recent models): http://unix.stackexchange.com/questions/259733/this-driver-is-deprecated-in-... Worth to try.
Ciao
Tried it, no good.
Seemed OK until I moved the mouse cursor into screen1, then it started flashing and tearing. Went back to xorg-x11-drv-intel.
Am 02.03.2016 um 19:44 schrieb Neal Becker:
Luigi Toscano wrote:
On Wednesday 02 of March 2016 16:20:47 Sudhir Khanger wrote:
My system is broken. It's a Thinkpad T420s with Intel 4400 integrated graphic card.
Can you please try to remove the -intel driver and try the modesetting one?
Debian recently decided to deprecate the -intel in favour of the generic one (which should work on recent models): http://unix.stackexchange.com/questions/259733/this-driver-is-deprecated-in-... Worth to try.
Ciao
Tried it, no good.
Seemed OK until I moved the mouse cursor into screen1, then it started flashing and tearing. Went back to xorg-x11-drv-intel
well, you have a real old machine - we don't own anything below SandyBrdige and that's now 5 years ago
please realize that Intel would do more harm with defaults adressing your hardware and spit in the face of everyone who is buying recent one by disable most of the features and performance - that's not how the IT world works
you have HW which don't work well with DRI3 - disabale it
but don't expect that every user out there with new hardware is supposed to dig in the configs to enable featutres which are available fpr 5 years and then wonder they all complain how shitty Linux works just because ancient users hsould not be forced to modify their config
Reindl Harald wrote:
Am 02.03.2016 um 19:44 schrieb Neal Becker:
Luigi Toscano wrote:
On Wednesday 02 of March 2016 16:20:47 Sudhir Khanger wrote:
My system is broken. It's a Thinkpad T420s with Intel 4400 integrated graphic card.
Can you please try to remove the -intel driver and try the modesetting one?
Debian recently decided to deprecate the -intel in favour of the generic one (which should work on recent models): http://unix.stackexchange.com/questions/259733/this-driver-is-deprecated-in-... Worth to try.
Ciao
Tried it, no good.
Seemed OK until I moved the mouse cursor into screen1, then it started flashing and tearing. Went back to xorg-x11-drv-intel
well, you have a real old machine - we don't own anything below SandyBrdige and that's now 5 years ago
please realize that Intel would do more harm with defaults adressing your hardware and spit in the face of everyone who is buying recent one by disable most of the features and performance - that's not how the IT world works
you have HW which don't work well with DRI3 - disabale it
but don't expect that every user out there with new hardware is supposed to dig in the configs to enable featutres which are available fpr 5 years and then wonder they all complain how shitty Linux works just because ancient users hsould not be forced to modify their config
I don't think you meant this as a reply to me, my machine is only 1 year old. 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
Am 02.03.2016 um 19:55 schrieb Neal Becker:
Reindl Harald wrote:
well, you have a real old machine - we don't own anything below SandyBrdige and that's now 5 years ago
please realize that Intel would do more harm with defaults adressing your hardware and spit in the face of everyone who is buying recent one by disable most of the features and performance - that's not how the IT world works
you have HW which don't work well with DRI3 - disabale it
but don't expect that every user out there with new hardware is supposed to dig in the configs to enable featutres which are available fpr 5 years and then wonder they all complain how shitty Linux works just because ancient users hsould not be forced to modify their config
I don't think you meant this as a reply to me, my machine is only 1 year old. 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
no, it was directed to the guy with "Thinkpad T420s with Intel 4400 integrated graphic card" and starting this thread with "What do Intel maintainers want to achieve by intentionally breaking system of so many people?"
On Wed, Mar 02, 2016 at 07:52:00PM +0100, Reindl Harald wrote:
well, you have a real old machine - we don't own anything below SandyBrdige and that's now 5 years ago
whatever works should not be broken by improvements. Otherwise I will go back to the C64 pretty soon (another 30 years or so).
Richard
Thinkpad T420 is also a Sandy Bridge machine. I tried enabling DRI2 but that causes flickering in while scrolling in Chrome.
I switched to i3. My system runs much more faster and using i3 knocked off at least 10C from system temperature.
On Ter, 2016-03-08 at 16:33 +0000, Sudhir Khanger wrote:
Thinkpad T420 is also a Sandy Bridge machine. I tried enabling DRI2 but that causes flickering in while scrolling in Chrome.
I sometimes got a flick but the fault is kernel 4.4 , I think .
I switched to i3. My system runs much more faster and using i3 knocked off at least 10C from system temperature. _______________________________________________ kde mailing list kde@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kde@lists.fedoraproject.or g
On Ter, 2016-03-08 at 18:15 +0000, Sérgio Basto wrote:
On Ter, 2016-03-08 at 16:33 +0000, Sudhir Khanger wrote:
Thinkpad T420 is also a Sandy Bridge machine. I tried enabling DRI2 but that causes flickering in while scrolling in Chrome.
I sometimes got a flick but the fault is kernel 4.4 , I think .
https://bugzilla.redhat.com/show_bug.cgi?id=1313318
BTW it is fixed in kernel-4.4.4-301.fc23 https://bodhi.fedoraproject.org/updates/FEDORA-2016-e6cfaff4b1
I switched to i3. My system runs much more faster and using i3 knocked off at least 10C from system temperature. _______________________________________________ kde mailing list kde@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kde@lists.fedoraproject. or g
On Sáb, 2016-02-20 at 08:46 -0600, Rex Dieter wrote:
In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too.
you may try add:
# cat /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "uxa" #Option "AccelMethod" "sna" EndSection
reading https://bbs.archlinux.org/viewtopic.php?id=208427
and because opengl direct rendering, doesn't work in VirtualBox (released yesterday, 4.0.16 ) with Fedora 24 branch KDE, we may try change AccelMethod , to see if fix something. With "my" KDE4 it working great even better than before , so unfortunately my deduction is, Plasma 5 have some serious graphic problems , but what and where ? , but is just with Intel graphics boards ? , anyway I will build KDE4 workspace and friends for F24 . We need understand from where came this deadlocks and fix it of course. But note I don't mean all KDE 5 is bad , I just use kde workspace from KDE4 the rest is all Fedora out out the box , may goal on next bunch of packages for F24 , reduce even more the number of package , for example I'm plan use oxygen-themes etc of official release.
Best regards,
(*) I just use kde workspace from KDE4, the rest is all Fedora KDE out of the box, my goal on next bunch of packages for F24 is reduce even more the number of packages, for example I'm planning use oxygen-themes stuff from official release.
Sérgio Basto wrote:
On Sáb, 2016-02-20 at 08:46 -0600, Rex Dieter wrote:
In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too.
you may try add:
# cat /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "uxa" #Option "AccelMethod" "sna" EndSection
?? When I read this link, it says he tried that fix ^^ and it didn't work. What's working for me is
Section "Device" Identifier "Intel_Graphics" Driver "intel" Option "DRI" "2" EndSection
Am 08.03.2016 um 14:06 schrieb Neal Becker:
Sérgio Basto wrote:
On Sáb, 2016-02-20 at 08:46 -0600, Rex Dieter wrote:
In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too.
you may try add:
# cat /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "uxa" #Option "AccelMethod" "sna" EndSection
?? When I read this link, it says he tried that fix ^^ and it didn't work. What's working for me is
Section "Device" Identifier "Intel_Graphics" Driver "intel" Option "DRI" "2" EndSection
well, and for others it's
Section "Device" Identifier "Videocard0" Option "AccelMethod" "uxa" Option "TearFree" "true" Option "DRI" "3" EndSection
and so there is no identical solution for every environment and on my machine (identical hardware) the config below works perfectly
Section "Device" Identifier "Videocard0" Option "AccelMethod" "sna" Option "TearFree" "true" Option "DRI" "3" EndSection
On Ter, 2016-03-08 at 14:11 +0100, Reindl Harald wrote:
Am 08.03.2016 um 14:06 schrieb Neal Becker:
Sérgio Basto wrote:
On Sáb, 2016-02-20 at 08:46 -0600, Rex Dieter wrote:
In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too.
you may try add:
# cat /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "uxa" #Option "AccelMethod" "sna" EndSection
?? When I read this link, it says he tried that fix ^^ and it didn't work. What's working for me is
Section "Device" Identifier "Intel_Graphics" Driver "intel" Option "DRI" "2" EndSection
well, and for others it's
Section "Device" Identifier "Videocard0" Option "AccelMethod" "uxa" Option "TearFree" "true" Option "DRI" "3" EndSection
and so there is no identical solution for every environment and on my machine (identical hardware) the config below works perfectly
Section "Device" Identifier "Videocard0" Option "AccelMethod" "sna" Option "TearFree" "true" Option "DRI" "3" EndSection
and just ?
Section "Device" Identifier "Videocard0" Option "TearFree" "true" EndSection
Well, you have a nice bug report to send upstream , saying something like this: without TearFree plasma5 have deadlooks , please fix it ! :)
Best regards,
Sérgio Basto wrote:
On Ter, 2016-03-08 at 14:11 +0100, Reindl Harald wrote:
Am 08.03.2016 um 14:06 schrieb Neal Becker:
Sérgio Basto wrote:
On Sáb, 2016-02-20 at 08:46 -0600, Rex Dieter wrote:
In the not-too-distant past, a xorg-x11-drv-intel update reverted back to default dri2 because dri3 was to unstable and too-often resulted in plasmashell freezes, see also: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8616 https://bugzilla.redhat.com/show_bug.cgi?id=1223477 https://bugzilla.redhat.com/show_bug.cgi?id=1223477
A new update came this past week turning dri3 back on, https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced at least 3 plasmashell deadlocks (when left idle and screen off) similar to past results when using dri3. And... oddly, chrome seems to freeze similar to plasmashell sometimes too.
you may try add:
# cat /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "uxa" #Option "AccelMethod" "sna" EndSection
?? When I read this link, it says he tried that fix ^^ and it didn't work. What's working for me is
Section "Device" Identifier "Intel_Graphics" Driver "intel" Option "DRI" "2" EndSection
well, and for others it's
Section "Device" Identifier "Videocard0" Option "AccelMethod" "uxa" Option "TearFree" "true" Option "DRI" "3" EndSection
and so there is no identical solution for every environment and on my machine (identical hardware) the config below works perfectly
Section "Device" Identifier "Videocard0" Option "AccelMethod" "sna" Option "TearFree" "true" Option "DRI" "3" EndSection
and just ?
Section "Device" Identifier "Videocard0" Option "TearFree" "true" EndSection
Well, you have a nice bug report to send upstream , saying something like this: without TearFree plasma5 have deadlooks , please fix it ! :)
Best regards,
Interesting, if I try that (just TearFree), I get segfault from sddm
Am 08.03.2016 um 20:59 schrieb Neal Becker:
Interesting, if I try that (just TearFree), I get segfault from sddm
for me sddm is currently unstable as hell (maybe because TearFree and other options which are working well in daily use)
unstable means: boot a machine, after a unknown amount of time the dsiply manager hangs, just the classical X-cursor, VT "systemctl restart display-manager", login, all is fine
for a ordinary user likely horrible, the two times each day i need to login in both of my machines (home and office, both synced) acceptable
the typical logs due restart:
Process 3579 (sddm-greeter) of user 104 dumped core.#012#012Stack trace of thread 3579:#012#0 0x00007fd44f0a22e1 _ZN16QCoreApplication9postEventEP7QObjectP6QEventi (libQt5Core.so.5)#012#1 0x0000556b51b78f11 _ZN4SDDM10GreeterApp19removeViewForScreenEP10QQuickView (sddm-greeter)#012#2 0x00007fd44f0cf127 _ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)#012#3 0x00007fd44f5d2e12 _ZN15QGuiApplication13screenRemovedEP7QScreen (libQt5Gui.so.5)#012#4 0x00007fd44f601e12 _ZN7QScreenD1Ev (libQt5Gui.so.5)#012#5 0x00007fd44f6021f9 _ZN7QScreenD0Ev (libQt5Gui.so.5)#012#6 0x00007fd44f5c8b89 _ZN20QPlatformIntegration13destroyScreenEP15QPlatformScreen (libQt5Gui.so.5)#012#7 0x00007fd43d9441cc _ZN14QXcbConnection13destroyScreenEP10QXcbScreenb (libQt5XcbQpa.so.5)#012#8 0x00007fd43d9454cb _ZN14QXcbConnection13updateScreensEPK24xcb_randr_notify_event_t (libQt5XcbQpa.so.5)#012#9 0x00007fd43d945e93 _ZN14QXcbConnection14handleXcbEventEP19xcb_generic_event_t (libQt5XcbQpa.so.5)#012#10 0x00007fd43d946433 _ZN14QXcbConnection16processXcbEventsEv (libQt5XcbQpa.so.5)#012#11 0x00007fd44f0d0161 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5)#012#12 0x00007fd44f0a0609 _ZN16QCoreApplication6notifyEP7QObjectP6QEvent (libQt5Core.so.5)#012#13 0x00007fd44f0a073b _ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent (libQt5Core.so.5)#012#14 0x00007fd44f0a2b36 _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5)#012#15 0x00007fd44f0f6aa3 _ZL23postEventSourceDispatchP8_GSourcePFiPvES1_ (libQt5Core.so.5)#012#16 0x00007fd449045e3a g_main_context_dispatch (libglib-2.0.so.0)#012#17 0x00007fd4490461d0 g_main_context_iterate.isra.29 (libglib-2.0.so.0)#012#18 0x00007fd44904627c g_main_context_iteration (libglib-2.0.so.0)#012#19 0x00007fd44f0f6eaf _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)#012#20 0x00007fd44f09deca _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)#012#21 0x00007fd44f0a5fac _ZN16QCoreApplication4execEv (libQt5Core.so.5)#012#22 0x0000556b51b63088 main (sddm-greeter)#012#23 0x00007fd44e1e0580 __libc_start_main (libc.so.6)#012#24 0x0000556b51b63139 _start (sddm-greeter)#012#012Stack trace of thread 3580:#012#0 0x00007fd44e2b6fdd poll (libc.so.6)#012#1 0x00007fd450da1272 _xcb_conn_wait (libxcb.so.1)#012#2 0x00007fd450da2ee7 xcb_wait_for_event (libxcb.so.1)#012#3 0x00007fd43d943da9 _ZN15QXcbEventReader3runEv (libQt5XcbQpa.so.5)#012#4 0x00007fd44eebf3de _ZN14QThreadPrivate5startEPv (libQt5Core.so.5)#012#5 0x00007fd44dda660a start_thread (libpthread.so.0)#012#6 0x00007fd44e2c2a4d __clone (libc.so.6)#012#012Stack trace of thread 6036:#012#0 0x00007fd44e2b6fdd poll (libc.so.6)#012#1 0x00007fd44904616c g_main_context_iterate.isra.29 (libglib-2.0.so.0)#012#2 0x00007fd44904627c g_main_context_iteration (libglib-2.0.so.0)#012#3 0x00007fd44f0f6eaf _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)#012#4 0x00007fd44f09deca _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)#012#5 0x00007fd44eeba434 _ZN7QThread4execEv (libQt5Core.so.5)#012#6 0x00007fd45025d9b5 _ZN17QQmlThreadPrivate3runEv (libQt5Qml.so.5)#012#7 0x00007fd44eebf3de _ZN14QThreadPrivate5startEPv (libQt5Core.so.5)#012#8 0x00007fd44dda660a start_thread (libpthread.so.0)#012#9 0x00007fd44e2c2a4d __clone (libc.so.6)
This fixed it for me as well, had some game freezes with DRI3 enabled.
Rex Dieter wrote:
Please help test this if you are able.
For *me*, it's pretty good, but I've now experienced
at least 3
plasmashell deadlocks (when left idle and screen
off) similar to past
results when using dri3. And... oddly, chrome seems to freeze similar
to plasmashell
sometimes too.
I have had exactly these symptoms since a week or two corresponding to about the time of the intel update. I had changed no settings at all, but plasma would be locked after a period of idleness and turned-off screen.
I don't know if this has anything to do with it, but I changed the default openGL2/GLX to openGL3.1/EGL and, one day later, I have had no problems.
Before, when I opened Firefox, too, there were curiosities: the program would open in a small size and the rest of the desktop would be black. It would stick like that for a moment, before expanding to full size. Now, with openGL3.1/EGL, it just opens full screen right away.
Holy Manatee, this is confusing!
Ok. Videos showing black was not openGL3.1/EGL, it was Totem!
But, I did put that TearFree true line into xorg.conf.d and restarted X. Too early to tell about plasma lockups, though.
I read that EGL is supposed to be the interface for Wayland, so I thought I'd give it a try now.
So, I'm trying TearFree, openGL3.1 and EGL all enabled for a few days ;-)
P. Gueckel wrote:
I don't know if this has anything to do with it, but
I
changed the default openGL2/GLX to openGL3.1/EGL
and,
one day later, I have had no problems.
Scratch that one ;-) I just tried playing some videos and there is just a black screen. I think I experimented with openGL3.1 a year or so ago and it was the same problem.
I'll give some of those xorg.conf variations a try later :-(
attention kernel-4.4.4-301.fc23 have many complains in last days .
https://bodhi.fedoraproject.org/updates/FEDORA-2016-e6cfaff4b1
On Seg, 2016-03-14 at 15:44 -0600, P. Gueckel wrote:
Holy Manatee, this is confusing!
Ok. Videos showing black was not openGL3.1/EGL, it was Totem!
But, I did put that TearFree true line into xorg.conf.d and restarted X. Too early to tell about plasma lockups, though.
I read that EGL is supposed to be the interface for Wayland, so I thought I'd give it a try now.
So, I'm trying TearFree, openGL3.1 and EGL all enabled for a few days ;-) _______________________________________________ kde mailing list kde@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kde@lists.fedoraproject.or g
Am 15.03.2016 um 00:02 schrieb Sérgio Basto:
attention kernel-4.4.4-301.fc23 have many complains in last days .
https://bodhi.fedoraproject.org/updates/FEDORA-2016-e6cfaff4b1
but who cares about 4.4.4?
[root@srv-rhsoft:~]$ uname -a Linux srv-rhsoft.rhsoft.net 4.4.5-300.fc23.x86_64 #1 SMP Thu Mar 10 17:54:44 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
not that 4.4.4 had any problems on 6 different machines with intel graphics....
On Seg, 2016-03-14 at 15:44 -0600, P. Gueckel wrote:
Holy Manatee, this is confusing!
Ok. Videos showing black was not openGL3.1/EGL, it was Totem!
But, I did put that TearFree true line into xorg.conf.d and restarted X. Too early to tell about plasma lockups, though.
I read that EGL is supposed to be the interface for Wayland, so I thought I'd give it a try now.
So, I'm trying TearFree, openGL3.1 and EGL all enabled for a few days ;-)
P. Gueckel wrote:
I'm trying TearFree, openGL3.1 and EGL all enabled for a few days ;-)
Referring to the previous discussion, it likely is TearFree that solved the occasional Plasma lockups that occurred after idling/screen blacking, but this trio of experiments works perfectly here for 5 days running.
Am 19.03.2016 um 23:16 schrieb P. Gueckel:
P. Gueckel wrote:
I'm trying TearFree, openGL3.1 and EGL all enabled for a few days ;-)
Referring to the previous discussion, it likely is TearFree that solved the occasional Plasma lockups that occurred after idling/screen blacking, but this trio of experiments works perfectly here for 5 days running
but "TearFree" don't solve my machine completly freezing due heavy IO shortly ater KDE login while i have "TearFree" enabled on SandyBrdige/IvyBridge enabled the last 5 years as well as DRI3 enabled long ago
can't remember a update wtih such a bad impact as Xorg 1.18.2 "masked" as minor-update has (except the kernel some times ago freezing machines due raid-check)
On Sat, Mar 19, 2016 at 3:20 PM, Reindl Harald h.reindl@thelounge.net wrote:
can't remember a update wtih such a bad impact as Xorg 1.18.2 "masked" as minor-update has (except the kernel some times ago freezing machines due raid-check)
Harald... agreed, it's a significant impact... FWIW, the 1.18.2 hang isn't limited to intel cards... I have two machines which have Radeon and they both are impacted. IMHO it should be unpushed and not resubmitted until upstream gets it identified and resolved.
Am 20.03.2016 um 02:46 schrieb Gerald B. Cox:
On Sat, Mar 19, 2016 at 3:20 PM, Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net> wrote:
can't remember a update wtih such a bad impact as Xorg 1.18.2 "masked" as minor-update has (except the kernel some times ago freezing machines due raid-check)
Harald... agreed, it's a significant impact... FWIW, the 1.18.2 hang isn't limited to intel cards... I have two machines which have Radeon and they both are impacted. IMHO it should be unpushed and not resubmitted until upstream gets it identified and resolved
it should never have been pushed to updates-testing *4 days* after the koji build was finished and a bugreport filed and i am tired as one who has updates-testing on all the time type "--exclude=xorg*" to not render my machine unusable
On Sat, Mar 19, 2016 at 9:39 PM, Reindl Harald h.reindl@thelounge.net wrote:
it should never have been pushed to updates-testing *4 days* after the koji build was finished and a bugreport filed and i am tired as one who has updates-testing on all the time type "--exclude=xorg*" to not render my machine unusable
Agreed... I updated karma for both F23 / F24 with this:
Please reference: https://bugs.freedesktop.org/show_bug.cgi?id=94515
As you can tell from the karma above, this update is toxic and needs to be unpushed. It should not be resubmitted until upstream resolves.
On 03/20/2016 12:29 PM, Neal Becker wrote:
Reindl Harald wrote:
TearFree, openGL3.1 and EGL
What is the config you used to enable these options?
openGL3.1 and EGL are in KDE System Settings. Display and Monitor -> Compositor
Am 20.03.2016 um 16:29 schrieb Neal Becker:
Reindl Harald wrote:
TearFree, openGL3.1 and EGL
What is the config you used to enable these options?
OpenGL & friends is in the kde settings
[root@rh:~]$ cat /etc/X11/xorg.conf.d/03-intel.conf Section "Device" Identifier "Videocard0" Option "AccelMethod" "sna" Option "TearFree" "true" Option "DRI" "3" EndSection
Am 20.03.2016 um 17:05 schrieb Reindl Harald:
Am 20.03.2016 um 16:29 schrieb Neal Becker:
Reindl Harald wrote:
TearFree, openGL3.1 and EGL
What is the config you used to enable these options?
OpenGL & friends is in the kde settings
[root@rh:~]$ cat /etc/X11/xorg.conf.d/03-intel.conf Section "Device" Identifier "Videocard0" Option "AccelMethod" "sna" Option "TearFree" "true" Option "DRI" "3" EndSection
BTW - what are these idiotic bodhi-mails which arrive mutiple times for some packages?
bodhi - 2016-03-18 18:21:37.973855 (karma: 0) kde-baseapps-15.12.3-1.fc23 kde-runtime-15.12.3-1.fc23 kdelibs-4.14.18-2.fc23 ejected from the push because u"Cannot find relevant tag for kdelibs-4.14.18-2.fc23. None of ['f23-updates-candidate', 'f23-updates-pending'] are in [u'f24-updates-testing', u'epel7-testing', u'dist-6E-epel-testing', u'dist-5E-epel-testing', u'f22-updates-testing', u'f23-updates-testing', u'f21-updates-testing']."
bodhi - 2016-03-20 16:00:22.782662 (karma: 0) xorg-x11-server-1.18.2-1.fc23 ejected from the push because u"Cannot find relevant tag for xorg-x11-server-1.18.2-1.fc23. None of [] are in [u'f24-updates-candidate', u'epel7-testing-candidate', u'dist-6E-epel-testing-candidate', u'dist-5E-epel-testing-candidate', u'f22-updates-candidate', u'f23-updates-candidate', u'f21-updates-candidate']."
Neal Becker wrote:
What is the config you used to enable these options?
/etc/X11/xorg.conf.d/20-intel.conf:
Section "Device" Identifier "Videocard0" Option "TearFree" "true" EndSection
The other two may be set in KDE's System Settings under Hardware/Display and Monitor/Compositor.
I tried openGL3.1 back in Fedora 21 and I had some problems. Then, it was considered experimental. The experimental designation is absent in Fedora 23. EGL is supposed to be the future, so I thought I give it a try. Almost a week now, no issues :-)
Hi, On Sáb, 2016-03-19 at 16:16 -0600, P. Gueckel wrote:
P. Gueckel wrote:
I'm trying TearFree, openGL3.1 and EGL all enabled for a few days ;-)
Referring to the previous discussion, it likely is TearFree that solved the occasional Plasma lockups that occurred after idling/screen blacking, but this trio of experiments works perfectly here for 5 days running.
What is the configuration that you have (running by last 5 days) ?
Thanks,