8086:2e12 Wallpaper hashed using sxa

Jan 4 vivid 64 .iso still same problem, wallpaper vertical bars and hashed.

Rebooted latest update vivid.

Monitor is 1920x1080., vertical bar background. Internet windows and terminal windows fine.

Tried 1360x768. Wallpaper Vertical bars.

Tried 1280x720. Vertical bars.

Tried 1024x768. Wallpaper O.K. but figure is stretched horizontally, i.e. fat because resolution geometry 4:3 doesn't fit screen 16:9.

Switched back to 1360x768, Wallpaper now O.K. ???

Conclusion, something screwed up in the calculations for varying resolution from 1920x768 (tiny print) to legible 1360x768. Only calculation that's reliable is 1024x768, which is 4:3 does not look good on this 16:9 screen besides being too coarse.

What code does the calculations for choice of pixels for varying resolutions? lightdm? Xorg? Unity?

Sure would help if Bug #1405867 were fixed so that selecting different wallpapers actually changed the wallpaper instead of having to reboot to get different wallpaper.

Appreciate any thoughts on this situation.

I don't think this is a gfx bug, but perhaps on nautilus which is handling it

Still present on every boot. See attachment.

DISTRIB_RELEASE=15.04
DISTRIB_CODENAME=vivid
DISTRIB_DESCRIPTION="Ubuntu Vivid Vervet (development branch)"
Linux Lenovo2 3.18.0-12-generic #13-Ubuntu SMP Thu Jan 29 04:35:32 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

Workaround is Files > Pictures > wallpaper.jpg right mouse click set wallpaper. May have to do it more than once.

My other pc's with different VGA controllers don't have this problem.

jerrylamos, could you please comment to which package upgrade specifically correlates to this issue?

Testing vervid I do updates most days and installs every couple weeks.
Typically there are a whole pile of packages (!) so us users don't install package by package so we can't tell which caused the trouble.
I reported the bug on Dec. 19 and the bug persists on every update and every couple weeks a new .iso install still has the bug example this one zsync'd a couple days ago.

Now of course 14.04 and 14.10 and earlier 15.04's do not have the bug. Neither does Win7.

The closest I can get to the bug is:
Boot
Wallpaper hashed. Drop down windows O.K.
File > Pictures > right click on desired jpg - I've tried a number, both mine and the ubuntu wallpapers
Set as Wallpaper
After one or two or three tries the wallpaper is correct, no hash.

What packages are involved in "Set as Wallpaper"?

Thanks for looking at this bug.

I run ubuntu vivid 64 on this Lenovo M58p. I haven't tried ubuntu vivid 32.

jerrylamos, so checking your update history from 2014-12-19, what precisely was updated that correlated to this problem?

Downloaded today's vivid 32 bit, booted live environment, systems settings appearance, set wallpaper
selected ubuntu skyscraper image
all hashed up.

See attachment.

Doesn't seem to make any difference, 32 bit or 64 bit both broken.

Comment #7, where is the update history found?
Likely hundreds of updates in December.
This install is a couple days old, still has the problem.
What packages are involved in "Set Wallpaper"?
Any way to put "Set Wallpaper" back to early December? All my vivid iso's are now in February.

Tried kernel 4-RC2

DISTRIB_DESCRIPTION="Ubuntu Vivid Vervet (development branch)"
Linux Lenovo2 4.0.0-040000rc2-generic #201503031836 SMP Tue Mar 3 18:37:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

No change, problem still hashes wallpaper on boot.

jerrylamos, could you please boot into the earliest vivid kernel you have installed and advise if this is reproducible?

Comment #11 found earlier vivid wallpaper works fine. (as does 14.10, 14.04, ...)
Nov. 10 vivid .iso fresh install on another partition.
Boots with wallpaper O.K. every time.

Vivid as of mid December updated/installed wallpaper screwed up on every boot.
This is a vivid apt-get update, apt-get dist-upgrade as of early March.
Wallpaper still screwed up on every boot.
Files > Pictures > Select jpg > set as wallpaper
has to be done maybe twice and then wallpaper O.K.
Kernel 4-RC2 or 3.19-7 no difference, wallpaper screws up on boot, then set wallpaper a couple times to get good wallpaper.

Both the older good vivid and the latest vivid are installed in separate partitions.

Any way to tell what packages are involved in "set wallpaper" and how to tell what changed?

Thanks.

until preceding updates ( yesterday mar 19) wallpaper was fine. after today (mar 20) updates wallpaper is dark gray. try change from Files > Pictures > Select jpg > set as wallpaper or from change desktop background - appearance: some pictures results in a dark gray background, other in dashed picture as from attachment.

System information report, generated by Sysinfo: 3/20/2015 8:33:41 AM
http://sourceforge.net/projects/gsysinfo

SYSTEM INFORMATION
 Running Ubuntu Linux, the Ubuntu 15.04 (vivid) release.
 GNOME: 3.14.1 (Ubuntu 2015-03-18)
 Kernel version: 3.16.0-24-generic (#32-Ubuntu SMP Tue Oct 28 13:07:32 UTC 2014)
 GCC: 4.9.2 (x86_64-linux-gnu)
 Xorg: 1.16.2.901 (1.16.3 RC 1) (17 February 2015 01:38:39PM) (17 February 2015 01:38:39PM)
 Hostname: corrado-vivid64
 Uptime: 0 days 0 h 50 min

corrado venturini, it would help immensely if you filed a new report via a terminal:
ubuntu-bug xorg

Please feel free to subscribe me to it.

done, but i don't know how subscribe you. my report is in:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1436378

Beta 2 Vivid hashed wallpaper problem on every single boot. Updated as of just now, amd64.
I did subscribe to bug in comment #15 I think.

I looked at the Lenovo support site.
The BIOS upgrade is for Win7 64 so I'll have to boot that ( if Ubuntu Grub hasn't screwed up the Win 7 bootloader ) and see if the download and exe will work.
Of course if a BIOS update fails I've got a dead computer.

Wily Werewolf here, updated as of 14 may, boots normally, no Hashing.

Reboot to 15.04, screen Hashed as usual.

Reboot to Wily Werewolf, boots normally again, no Hashing.

Wonder what next updates will do....

With the latest bios version the wallpaper is still hashed!
venetin@venetin-lenovo:~$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
[sudo] password for venetin:
5CKT77AUS
05/07/2012
venetin@venetin-lenovo:~$

As of 17 May Wily update,
xserver was updated
Now, hashing much harder to get rid of by multiple "set wallpaper".

How do I tell if the bug fix is in Wily? If so, it doesn't work. If not, when can I try the fix?

Thanks.

Bios update is in 1404247 - if it screws up I've got a dead computer.

1410 and before run just fine.

November and before 1504 ran fine. Win7 just fine. (Well, pretty slow it's Microsoft)

1504 December and on to now pretty bad. I have to "set wallpaper" multiple times.

At the moment, Wily much improved - maybe half the time boots to good wallpaper just fine, the other half needs one "set wallpaper".

Seems to be sensitive to xserver. Any way to try 1410 level of xserver in 1510?

Thanks, Jerry

The hashing is present also on all GTK applications. Look at the screenshot. The hashing is visible at the top right corner of the opened application. QT apps seems OK.

gsettings set org.gnome.desktop.background picture-uri 'file:////home/jerry/Pictures/Shark_Island.jpg'

re-does the wallpaper and can clean up the hashing.

What all does "gsettings" use? Likely xserver....

Wily O.K. for a couple weeks and I had my hpes up. Then got dread update:
xserver intel update

Now wallpeper usually boots horizontally striped hashed, sometimes boots wallpaper O.K.

I don't know how to down level xserver intel?

Wallpaper can be fixed by alternately doing the following once or twice or three times ...:

#!/bin/bash
gsettings set org.gnome.desktop.background picture-uri 'file:////home/jerry/Pictures/Shark_Island.jpg'
exit 0

alternately with

#!/bin/bash
gsettings set org.gnome.desktop.background picture-uri 'file:////home/jerry/Pictures/Shark_Island2.jpg'
exit 0

same jpg with two different names.

Other jpg's fail similarly including default wallpapers.

Note, similar to bug #1406802

[Expired for xorg (Ubuntu) because there has been no activity for 60 days.]

Wily as of

DISTRIB_RELEASE=15.10
DISTRIB_CODENAME=wily
DISTRIB_DESCRIPTION="Ubuntu Wily Werewolf (development branch)"
Linux Lenovo2 4.1.0-3-generic #3-Ubuntu SMP Tue Jul 28 12:25:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

very poor. I have to do settings > display > jpg several times to clear up wallpaper.

gsettings fail this resorts to the original brown screen:

gsettings set org.gnome.desktop.background picture-uri 'file:////home/jerry/Pictures/Shark_Island.jpg'

gsettings used to work. What happened?

Opened a bug for gsettings failure described in comment #26:

gsettings fails to set wallpaper 1490543

Gsettings fails on both the Lenovo M58p with the hashing problem
Gsettings also fails on Acer 5253 laptop which does not have the hashing problem

In both pc's Settings Appearance Wallpapers Pictures folder works, but on the Lenovo may have to be repeated several times.

Update complete Wily as of display.

Appearances Background all pictures horizontally hashed, both the ubuntu supplied ones and my jpg's.

Wallpaper horribly hashed and will not recover even with multiple wallpaper settings. which used to clear things up until the changes of last week.

Files Picture viewer looks just fine.

Not only the wallpaper, but the text windows hashed unreadable.

Worst yet.

Earlier Wily much better, 14.04 LTS perfect.

Wily getting worse and worse.

Much screen text hashed unreadable. A couple weeks ago it was just Wallpaper.

Do note, Files Pictures select jpg displays jpg just fine. Settings Appearance all hashed.

See attached screenshot.

Do note with hashed unreadable text as in gedit, selecting screenshot may clear up the text, after screenshot unreadable again.

Status says "Incomplete" What would you like?

Thanks.

15.10 (daily 10.09.2015) is completely hashed. It is unusable on Lenovo m58p (intel q43/45).
Since it is getting worse I don't think that this bug will be fixed soon. Maybe the solution is to switch to different flavor/distro.
The issue may be fixed when Ubuntu switch to Mir and Unity 8. Until then just stick with 14.04.

Thanks for looking at the bug.

I switch between Mily looking for bugs, and LTS when I can't get something done with Mily because I can't read the screen.

I might try another kernel from kernel-ppa/mainline.

I don't know how to downlevel X to say, whatever it was in November 2014 when everything was fine.

Very strange when Mily Files can display a jpg just fine, then Desktop and Terminal get it all screwed up. Must use different routines.

I have run other flavors. I come back to Unity when I can. I'm used to how to get things done with Unity.

Kernel:

linux-image-3.17.0-031700-generic_3.17.0-031700.201410060605_amd64.deb

works fine installed into Wily.
I think it's one of the last Utopic kernels

So my drill is, update or install latest Wily, verify screen display is all screwed up,

Then install a kernel that will work.

I'm not a developer so I've got no way to find what changed (lots!) that would affect screen display.

I am curious did someone test how the things are whit the display port, not the d-sub output? Is there any picture at all on the display port?

Comment #36, this is a desk top so the display is hooked to the VGA port. I think there's only one display port on this Lenovo M58p.

Interesting, boot with Wily kernel,
Background Wallpaper hashed
Settings Appearance Wallpapers thumbnails hashed
Files Pictures displays same jpg fine
command line Gsettings fails screen all brown does not display the desired jpg
gsettings set org.gnome.desktop.background picture-uri 'file:////home/jerry/Pictures/Shark_Island.jpg'

Reboot with Utopic kernel
Background Wallpaper still hashed
Settings Appearance Wallpapers thumbnails fine
Wallpaper displays just like Files Pictures
gsettings still fails: brown screen instead of the desired jpg
with Utopic kernel,
Settings Appearance Wallpaper works fine.

How come with Wily kernel Files Pictures jpg's display fine but Settings Appearance Wallpapers is hashed?

What's the difference in the code to display with Files vs. Settings Appearance?
Even in Settings Appearance, the little monitor picture is O.K. but the thumbnails are all hashed?

Thanks.

Comment #37: Yes, there is only one display port and one vga port. Since the only display port to vga adapter that I found localy available costs around 15 euros i decided to buy a new video adapter instead. I bought the cheapest low profile Nvidia g210 based video adapter and solved the issue for me. As I said before the bug is most likely not to be solved soon. Only three people are "affected". Maybe the bug is specific to our M58P only and not all the users of this PC are running Ubuntu with Unity or gnome.

Shotwell display badly hashed.

Image Viewer display just fine.

Both on the screen at the same time in the attached screenshot.

How do I get the display routine used by Image Viewer to be used by Shotwell and Lightdm?

Note, part of screen behind the images shows badly hashed unreadable desktop.

I update most days, verify bad screen display, then reboot Wily using the Utopic kernel and all is fine.

Latest Wily:
DISTRIB_DESCRIPTION="Ubuntu 15.10"
Linux Lenovo2 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

Wallpaper badly hashed. Files > Pictures > select jpg displays just fine.

Some screen text displayed fine, other text hashed such as top line Close Min Max

Files > Home badly hashed, select Screenshot and displays fine even after closing Screenshot.

Typing in some text unreadable hash, mouse click outside the window text now readable.

Wily kernel must be using different X calls.....

Best solution is Trusty Tahr linux image on top of Wily.

Finally a workaround was posted on Launchpad - I've been battling this bug for 11 months:

#sudo nano /usr/share/X11/xorg.conf.d/20-intel.conf

#Add the following lines
Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"

Option "AccelMethod" "uxa"
EndSection

#reboot

jerrylamos, to confirm this is an upstream issue, could you please test http://cdimage.ubuntu.com/daily-live/current/ and advise to the results?

That site looks like a fresh install to today's xenial 64. I've been running an update xenial now at 4.5 RC1; I'll do a fresh install and see what happens.

I tested
http://cdimage.ubuntu.com/daily-live/current/

Wallpaper badly garbled.

Images from ubuntu O.K., but any text sent by ubuntu badly garbled unreadable.

Fix in comment #41 works fine.

Do note, 14.04 LTS had been running fine until 1/29 update screwed up network, so I
re-installed 14.04
Surprise, 14.04 now garbled too. Fix in comment #41 worked fine.

It's a bit of a struggle. Booting the .iso text from ubuntu unreadable. I've done enough installs to guess what the choices are.

Re-boot after install complete, text from ubuntu badly garbled, I have to muddle around to find the fix #41 and reboot. Now fine.

jerrylamos, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions of 1.2 at https://01.org/linuxgraphics/documentation/how-report-bugs ?

Please provide a direct URL to your bug report once you have made it so that it may be tracked.

Thank you for your understanding.