Created attachment 136679 [details]
uncorrupted desktop
To give you a better idea of the corruption, here is a screenshot of the
desktop in normal circumstances.
possible duplicate for bug #104536 .. the symptoms look a= lot worse though
| Bug ID | 104599 |
|---|---|
| Summary | corrupted desktop graphics with latest git intel driver |
| Product | Mesa |
| Version | git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/DRI/i915 |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | zebul666@hotmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Created att=
achment 136678 [details]
photo of corrupted graphic on screen
I have ubuntu 17.10 with an intel i3-3217U cpu/gpu and using the oibaf PPA
repo.
With latest following package:
libgles2-mesa:amd64 (17.4~git1801070730.be144e~oibaf~a
xserver-xorg-video-nouveau:amd64 (1:1.0.15+git1712110734.048baf~oibaf~a
libdrm-nouveau2:amd64 (2.4.89+git1712180630.831036~oibaf~a
libdrm-nouveau2:i386 (2.4.89+git1712180630.831036~oibaf~a
xserver-xorg-video-amdgpu:amd64 (1.4.99+git1712271934.69e208~oibaf~a
libegl1-mesa-dev:amd64 (17.4~git1801070730.be144e~oibaf~a
libglapi-mesa:amd64 (17.4~git1801070730.be144e~oibaf~a
libglapi-mesa:i386 (17.4~git1801070730.be144e~oibaf~a
libxatracker2:amd64 (17.4~git1801070730.be144e~oibaf~a
libegl1-mesa:amd64 (17.4~git1801070730.be144e~oibaf~a
libgbm1:amd64 (17.4~git1801070730.be144e~oibaf~a
libdrm-amdgpu1:amd64 (2.4.89+git1712180630.831036~oibaf~a
libdrm-amdgpu1:i386 (2.4.89+git1712180630.831036~oibaf~a
libllvm5.0:amd64 (1:5.0.1-1~oibaf~a
libllvm5.0:i386 (1:5.0.1-1~oibaf~a
xserver-xorg-video-intel:amd64 (2:2.99.917+git1712201935.708255~oibaf~a
libwayland-egl1-mesa:amd64 (17.4~git1801070730.be144e~oibaf~a
libdrm2:amd64 (2.4.89+git1712180630.831036~oibaf~a
libdrm2:i386 (2.4.89+git1712180630.831036~oibaf~a
xserver-xorg-video-ati:amd64 (1:7.10.99+git1712281934.1fe8ca~oibaf~a
libgl1-mesa-dri:amd64 (17.4~git1801070730.be144e~oibaf~a
libgl1-mesa-dri:i386 (17.4~git1801070730.be144e~oibaf~a
libosmesa6:amd64 (17.4~git1801070730.be144e~oibaf~a
libosmesa6:i386 (17.4~git1801070730.be144e~oibaf~a
libgl1-mesa-glx:amd64 (17.4~git1801070730.be144e~oibaf~a
libgl1-mesa-glx:i386 (17.4~git1801070730.be144e~oibaf~a
xserver-xorg-video-radeon:amd64 (1:7.10.99+git1712281934.1fe8ca~oibaf~a
libdrm-intel1:amd64 (2.4.89+git1712180630.831036~oibaf~a
libdrm-intel1:i386 (2.4.89+git1712180630.831036~oibaf~a
libdrm-radeon1:amd64 (2.4.89+git1712180630.831036~oibaf~a
libdrm-radeon1:i386 (2.4.89+git1712180630.831036~oibaf~a
mesa-vdpau-drivers:amd64 (17.4~git1801070730.be144e~oibaf~a
mesa-vdpau-drivers:i386 (17.4~git1801070730.be144e~oibaf~a
libdrm-dev:amd64 (2.4.89+git1712180630.831036~oibaf~a
mesa-va-drivers:i386 (17.4~git1801070730.be144e~oibaf~a
libdrm-common:amd64 (2.4.89+git1712180630.831036~oibaf~a
I have a desktop screen corrupted like in the photo (screenshot did not
wworked)
Windows control did not work (wayland related ?)
This is running the new GNOME based Ubuntu GUI with Gnome-Shel= l Wayland, right? With "Windows control did not work" you mean it doesn't respond to mouse-clicks? In that case it is known bugs/limitations in gnome-shell for depth 30/10bpc mode. GNOME Shells picking code can't handle 10 bit per color channel. Additionally Gnome-Shells Wayland compositor doesn't handle anything but bgrx8888 or bgra8888 framebuffers in its drm/kms backend. It takes whatever framebuffer format it gets, e.g., bgrx1010102 and hands it to the kernel as bgrx8888, so the gpu misinterprets a 10 bit image as a 8 bit image during scanout, which ends badly.
(In reply to Mario Kleiner from comment #3) > This is running the new GNOME based Ubuntu GUI w= ith Gnome-Shell Wayland, > right? >=20 > With "Windows control did not work" you mean it doesn't resp= ond to > mouse-clicks? >=20 > In that case it is known bugs/limitations in gnome-shell for depth 30/= 10bpc > mode. GNOME Shells picking code can't handle 10 bit per color channel. >=20 > Additionally Gnome-Shells Wayland compositor doesn't handle anything b= ut > bgrx8888 or bgra8888 framebuffers in its drm/kms backend. It takes wha= tever > framebuffer format it gets, e.g., bgrx1010102 and hands it to the kern= el as > bgrx8888, so the gpu misinterprets a 10 bit image as a 8 bit image dur= ing > scanout, which ends badly. Right, so this is NOTOURBUG. Zebulon, your issue should disappear when you = do apt-get update again since allow_rgb10_configs defaults to 'false'. Mario, do you know if there us existing Gnome bug about this? (did not find such) Maybe easiest workaround for them would be to ignore 10bpc until pick= ing and kms backend is fixed.
I can't help you anymore. I removed oibaf repo and switch back= to original ubuntu driver.
(In reply to Tapani P=C3=A4lli from comment #4) > (In reply to Mario Kleiner from comment #3) > > This is running the new GNOME based Ubuntu GUI with Gnome-Shell W= ayland, > > right? > >=20 > > With "Windows control did not work" you mean it doesn't= respond to > > mouse-clicks? > >=20 > > In that case it is known bugs/limitations in gnome-shell for dept= h 30/10bpc > > mode. GNOME Shells picking code can't handle 10 bit per color cha= nnel. > >=20 > > Additionally Gnome-Shells Wayland compositor doesn't handle anyth= ing but > > bgrx8888 or bgra8888 framebuffers in its drm/kms backend. It take= s whatever > > framebuffer format it gets, e.g., bgrx1010102 and hands it to the= kernel as > > bgrx8888, so the gpu misinterprets a 10 bit image as a 8 bit imag= e during > > scanout, which ends badly. >=20 > Right, so this is NOTOURBUG. Zebulon, your issue should disappear when= you > do apt-get update again since allow_rgb10_configs defaults to 'false'. >=20 > Mario, do you know if there us existing Gnome bug about this? (did not= find > such) Maybe easiest workaround for them would be to ignore 10bpc until > picking and kms backend is fixed. None that i would know of. I haven't filed one so far.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | NEW | RESOLVED |
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this = link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/781.