Created attachment 384323 [details]
Close shot of resize cursor 1 inch away from window border

Created attachment 384324 [details]
Left/Main screen

Did you already try the autoadjust button of your monitor?

(In reply to comment #3)
> Did you already try the autoadjust button of your monitor?

That is not the problem. The monitor with the problem is a laptop panel and the other one is connected with a DVI/HDMI cable. Take a look at the attached photos and you'll understand the problem.

Ok. I understand. Definitely a weird issue. So it's an extended desktop. What are the resolutions being used?

The external left monitor is 1600x900 and the laptop panel on the right is 1440x900.

This is the command I use to setup the dual screen.
xrandr --output LVDS1 --mode 1440x900 --output HDMI1 --left-of LVDS1 --mode 1600x900

(In reply to comment #6)
> The external left monitor is 1600x900 and the laptop panel on the right is
> 1440x900.
> 
> This is the command I use to setup the dual screen.
> xrandr --output LVDS1 --mode 1440x900 --output HDMI1 --left-of LVDS1 --mode
> 1600x900

Honestly, doing this in one command line is known to be buggy. I would try it
in multiple command lines.

xrandr --output LVDS1 --mode 1440x900 
xrandr --output HDMI1 --mode 1600x900
xrandr --output LVDS1 --right-of HDMI

Does this fix the issue?

See previous comment. I hate the new behaviour, that comments are marked as private by default ...

I've never had a problem with this before on Suse or other distros. I also tried playing around with the settings in the KDE control panel and this configuration is the only one that had the problem. I think it's related to the experimental kernel. I would have reopened the other bug but the person responsible for the bug said to open new bugs with any issues we encountered.

I'll try doing each of the commands one at a time after a fresh reboot and let you know how it goes.

(In reply to comment #7)
> (In reply to comment #6)
> > The external left monitor is 1600x900 and the laptop panel on the right is
> > 1440x900.
> > 
> > This is the command I use to setup the dual screen.
> > xrandr --output LVDS1 --mode 1440x900 --output HDMI1 --left-of LVDS1 --mode
> > 1600x900
> 
> Honestly, doing this in one command line is known to be buggy. I would try it
> in multiple command lines.
> 
> xrandr --output LVDS1 --mode 1440x900 
> xrandr --output HDMI1 --mode 1600x900
> xrandr --output LVDS1 --right-of HDMI
> 
> Does this fix the issue?

I tried doing it this way and I get the same result.

BTW, what's the output of 'xrandr'?

(In reply to comment #11)
> BTW, what's the output of 'xrandr'?

I'm also having trouble with the display after the screen saver runs. I'm using an openGL screensaver. The display doesn't update correctly and it flashes showing different windows. I'll upload a video.

Here's the xrandr output.

After the system comes up before I've changed anything with xrandr

jdmulloy@titanium:~> xrandr 
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 304mm x 190mm
   1440x900       60.2*+   40.2  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
HDMI1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 443mm x 249mm
   1600x900       60.0 +
   1400x1050      60.0  
   1280x1024      60.0  
   1440x900       59.9* 
   1280x720       60.0  
   1024x768       75.1     60.0  
   832x624        74.6  
   800x600        75.0     60.3  
   720x576        50.0  
   720x480        59.9  
   640x480        75.0     60.0  
   720x400        70.1  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
TV1 disconnected (normal left inverted right x axis y axis)
jdmulloy@titanium:~> 


After running the commands to configure the displays.

jdmulloy@titanium:~> xrandr 
Screen 0: minimum 320 x 200, current 3040 x 900, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1440x900+1600+0 (normal left inverted right x axis y axis) 304mm x 190mm
   1440x900       60.2*+   40.2  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
HDMI1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 443mm x 249mm
   1600x900       60.0*+
   1400x1050      60.0  
   1280x1024      60.0  
   1440x900       59.9  
   1280x720       60.0  
   1024x768       75.1     60.0  
   832x624        74.6  
   800x600        75.0     60.3  
   720x576        50.0  
   720x480        59.9  
   640x480        75.0     60.0  
   720x400        70.1  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
TV1 disconnected (normal left inverted right x axis y axis)

xrandr output looks reasonable.

> I'm also having trouble with the display after the screen saver runs. I'm using
> an openGL screensaver. The display doesn't update correctly and it flashes
> showing different windows. I'll upload a video.

I guess that's a different issue.

Apparently that's a regression in the kernel.

I'm also hit by this bug after I did the update of the kernel (from the official update repository...)

I tried to compile the new version of the intel driver, but it did not help... So probably this is a kernel problem...

Might be worth noting that running, for example:

xrandr --output DVI1 --mode 1280x1024 --rate 75

: or other commands that appear to reset the second output will often temporarily resolve the problem, but the right-hand screen will revert to the broken, offset behaviour quite rapidly.

xrandr output with glitch, looks reasonable:

$ xrandr
Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 8192 x 8192
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0                               
   1152x864       75.0                                                
   1024x768       75.1     60.0                                       
   800x600        75.0     60.3                                       
   640x480        75.0     60.0   
   720x400        70.1                                                
DVI1 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 376mm x 301mm                                                              
   1280x1024      60.0 +   75.0*                                      
   1152x864       75.0                                                
   1024x768       75.1     60.0                                              
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  

And running:
           xrandr --output DVI1 --mode 1280x1024 --rate 60
: resolves the problem until I change desktop, when the redrawing reverts the glitch.

--same-as VGA1 doesn't display the behaviour, right-hand screen is a perfect clone at that point. If I swap the outputs (DVI1 --left-of VGA1), the VGA screen has the offset problem and the DVI is fine, so it's the +1280+0 output in a dual-screen set-up that is problematic, not a particular video-card output.

i am also hit by this bug. (intel gm45)
downgrade to kernel 2.6.34-12.3 avoids the problem.

only cloned output works right, with other settings the right(external) display is corrupted (no matter if i use 1024x768 or 1280x1024 as resolution).

I'm having exactly the same problem here on a lenovo T410s. This is the second issue I have to bear with on a *productive* system after that official broken kernel update (see also bug 638200).

For me this is particularly bad, because I lost the possibility to do dual-head presentations (aka "presenter view") with my laptop. Got bitten by it last week on an international conference. Audience was mainly the windows-using type. Guess what reputation Opensuse has among them now.

Maybe such new and unstable drivers shouldn't have been unleashed on unsuspecting users in a "stable" OS.

For those experiencing this I recommend switching to the older more stable Intel driver by putting the following in /etc/X11/xorg.conf.d/50-device.conf

Section "Device"
  Identifier "Default Device"
  Driver "intellegacy"
EndSection

I tried again, after the official opensuse kernel update to 2.6.34.7. The problem is still not solved...

Good news everybody. I have found what appears to be a reproducible workaround for this problem. Launching certain applications in full-screen and then re-enabling the dual screen removes the right-edge glitching persistently. frozen-bubble worked for me twice, and the effect has survived a day of use and suspending. Launch the game, go to full-screen if it starts windowed, run "xrandr --output DVI1 --mode 1280x1024 --rate 60 --right-of VGA1" or similar to re-enable your second screen, cheer as the systray is usable again.

Is there any chance that this regression is going to be fixed until the end of next week? I'm going to present at an international conference again, and I want to know whether I have to switch to ubuntu or fedora in order to be able to use dual-head presenter view. 

The frozen Bubble fullscreen workaround does not work for me. Rather, it switches my main screen back to the --preferred mode, which is unuseable due to flawed EDID in my monitor (bug #613165 which is still unsolved upstream). Double trouble. But this may point into the direction that the problem is mode-related.

Besides, I guess it would seem awkward if I start my presentation with an interlude of frozen bubbles... 

In addition, I think that the summary understates the problem - to me, it's definitely more than a "glitch", because, besides not being able to use presenter view it renders my dual-head setup at work unuseable.

I wasn't really suggesting we should all just run frozen-bubble and lump it, more hoping that my workaround would point someone in the right direction to effect a real fix.

The effect does seem to persist through suspension, so if you could find a way to avoid your other problem you could perhaps "fix" your setup in privacy before the presentation. Not ideal, but may beat an OS switch until this is fixed properly.

Did frozen-bubble work for anyone else?

(In reply to comment #24)
> Is there any chance that this regression is going to be fixed until the end of
> next week? I'm going to present at an international conference again, and I
> want to know whether I have to switch to ubuntu or fedora in order to be able
> to use dual-head presenter view. 
> 
> The frozen Bubble fullscreen workaround does not work for me. Rather, it
> switches my main screen back to the --preferred mode, which is unuseable due to
> flawed EDID in my monitor (bug #613165 which is still unsolved upstream).
> Double trouble. But this may point into the direction that the problem is
> mode-related.
> 
> Besides, I guess it would seem awkward if I start my presentation with an
> interlude of frozen bubbles... 
> 
> In addition, I think that the summary understates the problem - to me, it's
> definitely more than a "glitch", because, besides not being able to use
> presenter view it renders my dual-head setup at work unuseable.

Did you try the fix I described above? The old driver has been rock solid for me. I can't believe the SUSE devs unleashed this unstable, steaming pile of garbage on the masses. Use the old non-broken driver.

> Did you try the fix I described above? The old driver has been rock solid for
> me. 

You're right, I'm back to dual-head with the intellegacy driver. Thanks for the hint. 

> I can't believe the SUSE devs unleashed this unstable, steaming pile of
> garbage on the masses. 

Me too. I wonder what the point is in using an unstable driver, when the old one works better. Is there any reason why the old driver is not being used in the official setting?

The reason why we don't use intel's legacy driver is that it is no longer supported by Intel at all. Also it doesn't support the latest Intel GPUs like Ironlake, let alone SandyBridge. We package it as a fallback for users, for
whom the current intel driver still doesn't work. Looks like this has been a
good decision. Unfortunately these persons now request to have it as default
driver for any Intel GPU:-(

In case you're interested in testing the latest X/Kernel bits including latest Intel driver development,here is my HOWTO:

zypper ar -f \
  http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.3/ \
  Kernel:HEAD
zypper ar -f \
  http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.3/ \
  X11:XOrg
zypper mr -p 90 Kernel:HEAD
zypper mr -p 90 X11:XOrg
zypper ref
zypper dup
zypper in xorg-x11-server-debuginfo xorg-x11-server-debugsource \
          xorg-x11-driver-video-debuginfo xorg-x11-driver-video-debugsource \
          xorg-x11-driver-input-debuginfo xorg-x11-driver-input-debugsource \
          libpixman-1-0-debuginfo libpixman-1-0-debugsource \
          libpciaccess0-debuginfo libpciaccess0-debugsource

No promises given that this fixes your issues. It might even break your system completely.

(In reply to comment #28)
> The reason why we don't use intel's legacy driver is that it is no longer
> supported by Intel at all. Also it doesn't support the latest Intel GPUs like
> Ironlake, let alone SandyBridge. 

Ironlake works well with the intellegacy driver on my Lenovo T410s (Core i5 M 520). But now I understand that we should not take this functionality for granted, i.e., it may break any time. Having a working intel driver in the near future is definitely the better option.

> We package it as a fallback for users, for
> whom the current intel driver still doesn't work. Looks like this has been a
> good decision. Unfortunately these persons now request to have it as default
> driver for any Intel GPU:-(

Well, the point is that this is a regression. Dual-head configs were no problem until that new kernel came in with an official update. And sorry if my tone became a bit harsh in my comment above. It's just that I'm hit by the second regression in OpenSUSE within a few weeks.

> In case you're interested in testing the latest X/Kernel bits including latest
> Intel driver development,here is my HOWTO:

Sounds interesting, but does testing kernel HEAD and latest Xorg help fixing this regression in the released version? 

> No promises given that this fixes your issues. It might even break your system
> completely.

My problem is that I'm using 11.3 on a _productive_ system, and I can't afford breaking it completely.

(In reply to comment #29)
> Well, the point is that this is a regression. Dual-head configs were no 
> problem until that new kernel came in with an official update.

I wasn't aware this being a regression of an official kernel update.

> Sounds interesting, but does testing kernel HEAD and latest Xorg help fixing
> this regression in the released version? 

I guess it isn't.

> My problem is that I'm using 11.3 on a _productive_ system, and I can't afford
> breaking it completely.

I understand that.

I ran into this same problem today when doing a presentation.
So there is two workarounds
1) decrease kernel
2) use unsupported legacy driver

Do you know what cause this and is there any info that I provide to help solving this?

(In reply to comment #31)
> I ran into this same problem today when doing a presentation.
> So there is two workarounds
> 1) decrease kernel
> 2) use unsupported legacy driver
> 
> Do you know what cause this and is there any info that I provide to help
> solving this?

I would recommend using the legacy driver. I don't think it's unsupported it's just that it's not the latest and greatest, but at least it isn't broken.

If you back rev your kernel you'll probably run into bug 617530 which is why the update to the kernel that caused this bug took place to begin with. I tested the new kernel and filed this bug when I found that it was broken, they released it anyway. It makes sense though since this bug only affects dual head and it's not nearly as bad as freezing the whole system like the old kernel did.

It was stable with earlier version of kernel (gnome+compiz) for me. Everything worked well. As this is my netbook and primary purpose is presentation use this is MAJOR flaw for me. Now this problem happens in Gnome and KDE. This bug actually trigger me to install KDE.

I hate to say it, but this bug has me seeking temporary refuge with Fedora intill this is solved.  I wasn't able to get compositing working with the legacy driver (If I missed something, please let me know).  I "can" live without compositing, but I don't want to.

I still have openSUSE installed on a separate partition, so if there is testing that needs to be done, please let me know.

I'm pretty in line with the previous two comments. The only thing that keeps me with OpenSUSE is that I put it on every machine in our lab. After all, I've been with OpenSUSE for more than ten years now, since. 6.1. But then came the USB autosuspend regression which took weeks to be fixed, and now another regression which is around since weeks with _no_ comment by the one to whom the bug is assigned. I mean, we don't even know whether there is anyone working on it, or what we can do to help fix it.

This is not how a community driven OS makes progress. As soon as I have a little time I'll give Ubuntu another try.

So how can we help to solve this issue?

What info we could provide to you?

Lets keep this strict to problem solving only and rants to other time.

Seems this going to be monolog but with earlier kernel this not happens nor the hanging issue.

linux-9mu9:~> uname -a
Linux linux-9mu9.site 2.6.34.7-0.2-desktop #1 SMP PREEMPT 2010-09-14 14:21:06 +0200 x86_64 x86_64 x86_64 GNU/Linux

hwinfo --gfxcard
09: PCI 02.0: 0300 VGA compatible controller (VGA)              
  [Created at pci.318]
  Unique ID: _Znp.ocqHJHAoUZ0
  SysFS ID: /devices/pci0000:00/0000:00:02.0
  SysFS BusID: 0000:00:02.0
  Hardware Class: graphics card
  Model: "Mobile Intel® GM45 Express Chipset"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x2a42 "Mobile Intel® GM45 Express Chipset"
  SubVendor: pci 0x1025 "Acer Incorporated [ALI]"
  SubDevice: pci 0x029b 
  Revision: 0x07
  Driver: "i915"
  Driver Modules: "drm"
  Memory Range: 0xd0000000-0xd03fffff (rw,non-prefetchable)
  Memory Range: 0xc0000000-0xcfffffff (ro,non-prefetchable)
  I/O Ports: 0x30d0-0x30d7 (rw)
  IRQ: 27 (592737 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v00008086d00002A42sv00001025sd0000029Bbc03sc00i00"
  Driver Info #0:
    XFree86 v4 Server Module: intel
  Driver Info #1:
    XFree86 v4 Server Module: intel
    3D Support: yes
  Config Status: cfg=new, avail=yes, need=no, active=unknown


xrandr 
Screen 0: minimum 320 x 200, current 2806 x 900, maximum 8192 x 8192
VGA1 connected 1440x900+1366+0 (normal left inverted right x axis y axis) 408mm x 255mm
   1440x900       59.9*+
   1280x1024      75.0     60.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        72.8     75.0     66.7     60.0  
   720x400        70.1  
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm
   1366x768       60.0*+
   1024x768       85.0     75.0     70.1     60.0  
   832x624        74.6  
   800x600        85.1     72.2     75.0     60.3     56.2  
   640x480        85.0     72.8     75.0     59.9  
   720x400        85.0  
   640x400        85.1  
   640x350        85.1  
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)

(In reply to comment #37)
> Seems this going to be monolog but with earlier kernel this not happens nor the
> hanging issue.
> 

Did you try running OpenGL programs like glxgears or an OpenGL screensaver? Did you enable compositing effects? See what happens if you turn on effects and run an OpenGL screensaver. I'd be amazed if that doesn't cause your whole system to lock up.

So how long I need to run and verify that this not happen to me?
I did test to run screen saver and glxgear same time with compositing on and no locking.

attaching a screen shot.

Created attachment 396673 [details]
screenshot it compositing on

I'm having the same problem, and if I turn off the Desktop Effects, it goes away. I guess if you are doing presentation you could use this workaround.

In the openSUSE forum Fruchtratte suggested a fix: http://bit.ly/8ZJofM

He thinks the problem was in this commit: http://bit.ly/adG172

I tried this but I've got a compile error so I haven't been able to verify this.

Oh by the way, the discussion about this bug is in this thread:
http://bit.ly/aAetWX

After teh kernel update today, graphics began working with the default driver.  but ONLY without desktop effects turned on.

The ofset with compositing on is now only on the x (horizontal) axis by a couple cm. before it was offset on the y axis by about a cm.  Are the experiences of the other users?  I have been experimenting with compiling the driver myself and want to ensure I did not taint my system.

"After the kernel update today, graphics began working with the default driver. 
but ONLY without desktop effects turned on."

Actually it worked for me before the Kernel update if I had the desktop effects off. I don't think they made any progress about in this update. Hope it will be fixed soon.

Any info what can be provide to developer to get this solved?

Hasn't this been reported as kernel regression? So why is it now reassigned to X.Org component?

Sorry, was blindly cleaning up bugs, my fault...

Only bug owners, or project managers, can change the priority.

Can something be done about this already? Even if it's just a workaround such as temporarily rolling back affected systems to an earlier i915 module?

To summarize:

There are three workarounds:
- switch off compositing ("desktop effects")
- Use legacy intel driver (see comment #21) not recommended, not supported
- roll back kernel to the one distributed with stock 11.3, not recommended

There's a community-contributed tentative patch that fixes the issue here, including kernel patching walkthrough (from comment #41):
http://forums.opensuse.org/english/information-new-users/unreviewed-how-faq/448293-howto-solve-dual-monitor-problem-intel-graphic-cards-after-updating-kernel-11-3-a.html

Can the kernel devs look into this patch and, if suitable, include it in the next update? Thanks a lot!

A quick look at the kernel-source /usr/src/linux-2.6.34.7-0.5/drivers/gpu/drm/i915/intel_display.c looks like they did.   (around line 4302)(In reply to comment #50)
> To summarize:
> 
> There are three workarounds:
> - switch off compositing ("desktop effects")
> - Use legacy intel driver (see comment #21) not recommended, not supported
> - roll back kernel to the one distributed with stock 11.3, not recommended
> 
> There's a community-contributed tentative patch that fixes the issue here,
> including kernel patching walkthrough (from comment #41):
> http://forums.opensuse.org/english/information-new-users/unreviewed-how-faq/448293-howto-solve-dual-monitor-problem-intel-graphic-cards-after-updating-kernel-11-3-a.html
> 
> Can the kernel devs look into this patch and, if suitable, include it in the
> next update? Thanks a lot!

A quick look at the kernel-source /usr/src/linux-2.6.34.7-0.5/drivers/gpu/drm/i915/intel_display.c looks like they did apply it.

> A quick look at the kernel-source
> /usr/src/linux-2.6.34.7-0.5/drivers/gpu/drm/i915/intel_display.c looks like
> they did apply it.

Please ignore this comment, I misread the patch command in the thread.  The patch supplied is intended to be reversed (anti-patch).

According to:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commitdiff;h=52e68630d13f9668f8f4dd6978fa41039bacfaf6#patch1

The current offset calculations are required for some generations of Intel graphics cards.  My understanding then is that the patch from the forums would reintroduce https://bugs.freedesktop.org/show_bug.cgi?id=28518 and should be avoided. I have created a patch that follows the spirit of the above commit, without back-porting too much of the 36 series driver. I have tested it on my system and it works for me.

Created attachment 397890 [details]
page flipping offset fix

I'm happy to report that William Witt's fix at comment 54 https://bugzilla.novell.com/show_bug.cgi?id=633044#c54 worked for me as well. 

Fruchtratte updated how-to at http://forums.opensuse.org/english/information-new-users/unreviewed-how-faq/448293-howto-solve-dual-monitor-problem-intel-graphic-cards-after-updating-kernel-11-3-a.html so anyone can follow it.

Thank you very much, William.
-Joon

Great news. When do we expect this to be on update channel?

(In reply to comment #56)
> Great news. When do we expect this to be on update channel?

I'm not a kernel dev (and don't really have any desire to be), perhaps one of them could jump in and enlighten us.  If I need to submit the patch upstream instead, please let me know.

Filed bug and submitted patch upstream:

https://bugzilla.kernel.org/show_bug.cgi?id=22242

Still no response to the upstream bug.

Any chance for the openSUSE kernel maintainers to implement this patch

Just a note: The word "glitch" in the summary of this bug and the upstream bug understates the problem. It may cause developers to underestimate the severity of  this bug and ignore it. I suggest to change it to "regression" to better reflect the source of the problem.

http://intellinuxgraphics.org/2010Q3.html
https://bugs.freedesktop.org/show_bug.cgi?id=30295

Also the kernel update of today does not solve this problem...
However, I started using the updates from Tumbleweed (including the 2.6.36 kernel), where the problem does not longer occur.

Hello

I'm quite upset about the fact, that still little is done to solve the bug permanently.

Hoping my contribution could help to find a solution I add some observations I made on my HP6730b:

- The problem occurs when the second monitor has a different resolution than the one of the laptop. Both monitors will display the same resolutions - independently from the resolutions set via the KDE desktop settings
- When set to clone mode, this will show in one of the monitors displaying a wrong screen format
- When working as a desktop extension, one of the monitors will display its image with an offset. The mouse coordinates are rendered according to the proper resolution, so one has to click to the right of the desired spot to hit corresponding buttons.

Developers should be able to reproduce the bug, since so many people have the problem.  

Sincerely


Dieter Ernst

I've switched back to the new driver because I haven't been using my laptop in dual screen mode lately. Even without dual screen modes I'm having problems. It keeps freezing up on me. It usually happens right after I resume from suspending the machine but it just happened without me doing anything special. This new driver is garbage, I'm going back to the stable working driver.

As Wim De Meester said, if you add Tumbleweed repo, and update the kernel, the problem goes away.

Thanks for letting us know this is fixed in the latest kernel release, closing out.