#170 Scrolling corruption

closed-fixed
Visual (35)
6
2006-05-20
2005-10-29
Darkvater
No

Rdesktop 1.4.1

You are probably familiar with the problem. This is where you use an
NVIDIA driver (some have reported ATi as well) and you scroll up in any
window, the lines just get smashed an become corrupted, resulting in
being unable to read the window. Minimizing and reopening the window
fixes the problem until the next scroll (or drag of window up).

As people with ATi cards also report this I don't think this is a problem
with the driver itself; unless they both wrote the same bug in :). Could it
perhaps be that rdesktop has problems with gfx (2D) acceleration?

There is a thread on the NVIDIA forums about this: http://www.nvnews.
net/vbulletin/showthread.php?t=50434

Would really appreciate it if someone could look at it and try to fix this.
Otherwise I have no other problems with rdesktop, it just works great!

Discussion

  • Darkvater

    Darkvater - 2005-10-29

    Logged In: YES
    user_id=996227

    Oh, forgot to mention, I also tried the latest CVS version (as of today) and all the
    command line flags (not their combos) without any effect.

     
  • Darkvater

    Darkvater - 2005-10-29
    • priority: 5 --> 6
     
  • Ilya Konstantinov

    • assigned_to: nobody --> ikonst
     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    Sounds real bad, and genuinely reproducible. I'll try to
    reproduce it with my NVIDIA card[1] and latest drivers[2]
    and see what I can do.

    [1] nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)
    [2] 1.0.7174

     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    So far, didn't see any problems on the combo I've previously
    described, but I'll try to get a hold of more systems to
    test on.

     
  • Darkvater

    Darkvater - 2005-11-03

    Logged In: YES
    user_id=996227

    Strange. A lot of people on the forums have problems with the scrolling. Don't
    know if it's in 7174 as well; I can check later this weekend; I am using

    [1] 1.0-7676
    [2] Geforce FX5600

     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    Whoa, not sure how I missed it before. Of course I see it.
    I'll research this.

     
  • Ilya Konstantinov

    • status: open --> open-accepted
     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    When scrolling up (it doesn't happen when scrolling down),
    we'd have to:
    1. Copy the bitmap downwards (= screenblt)
    2. Add the small (scroll-delta sized) missing bitmap piece
    to top of the scrolled area (= memblt)

    From spending minutes upon minutes of scrolling, watching
    the artifacts and thinking what may cause them, it looks as
    if X performs the XPutImages and XCopyAreas in out-of-order
    in some unexpected fashion; as in, our screenblt might move
    a piece of the memblt'd image, although the memblt'ing
    should've happened only after the entire screenblt has
    finished clearing up the space for the new chunk. No clear
    idea in my head so far, though...

    Hope I'll see more tomorrow (keep in mind I don't have
    access to a video card I can reproduce this issue on very
    often)...

     
  • Nobody/Anonymous

    Logged In: NO

    I had some free time so I tried other NVidia drivers starting from 7167 (couldn't
    compile 6629). All of these; 7167, 7174, 7664, 7667 and current 7676 had the
    scrolling corruption. The MESA as stated before worked.

    Really hope you can find a solution to this :)

     
  • Nobody/Anonymous

    Logged In: NO

    I had nvidia drivers and used rdesktop for a long time
    without any problem
    till last week where I met this scrolling issue after I
    turned on the Composite extension.

    Turning off Composite extension fixes the problem at least
    for me.

    FC4 64bit, 7676, 6600GT.

     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    Whoa, this is a very useful detail you're providing. This
    sounds to this report:
    https://sourceforge.net/tracker/?func=detail&atid=111005&aid=1030467&group_id=11005

    According to them, it doesn't happen on non-32bpp visuals.
    Then again, I'm pretty sure I managed to reproduce it on a
    24bpp visual.

    Curiously, the bug is caused by simply enabling Composite,
    without any Composition Manager running. I wonder what
    implicit compositing is going on in this case...

     
  • Nobody/Anonymous

    Logged In: NO

    In case it helps.

    I think NVIDIA drivers allow only up to 24bit visuals but I
    am not sure.

    In any case I had the problem with 24bit visual.

    Without any Composition Manager. (I am sure because running
    it crashes X when s opengl screensaver runs.)

     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    No need to guess. Run xdpyinfo and see.
    1. Do you have "Composite" in the list of extensions?
    2. Do you have this visual:
    visual:
    visual id: 0x47
    class: TrueColor
    depth: 32 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    ?

     
  • Darkvater

    Darkvater - 2005-11-07

    Logged In: YES
    user_id=996227

    This is very, very interesting. I read through the Nedit bugreport as well as the
    XOrg link and tried:
    export XLIB_SKIP_ARGB_VISUALS=1
    rdesktop 192.168.1.100 -a 16

    and IT WORKED. No more scrolling corruption. I always had the composite
    manager turned on, never thought about turning it off. The XOrg link was:
    http://www.x.org/X11R6.8/doc/RELNOTES5.html#41

    Couldn't readily see how Nedit solved this.

     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    export XLIB_SKIP_ARGB_VISUALS=1
    will cause rdesktop not to use a 32bpp visual. I'll be
    surprised if a 32bpp visual was the cause of this problem,
    as my copy of rdesktop contains a patch (not commited yet)
    that avoids using 32bpp visuals and yet the problem was
    still reproducable on it.

    Unfortunatelly, I wasn't by my Nvidia machine this week so I
    wasn't able to research more. Maybe I'll either get a cheapo
    Nvidia card or get to a machine I can reproduce it on next week.

     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    Ah, my patch was no good. It prefered the native depth (i.e.
    RDP's depth) over 32bpp, but since my server only offers
    24bpp and 32bpp, it didn't prefer 24bpp over 32bpp and just
    chose the higher one.

    Anyway, 32bpp in Composite mode indeed seems to bring up an
    NVidia problem. I'll check again, but IIRC my Radeon 7000
    didn't exhibit such problems in Composite mode.

    The solution of bug #1055468 should eliminate the problem
    for all users, since NVidia always offers 24bpp as well.
    However, we'll be just covering up for a genuine NVidia bug
    that way.

     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    Confirming: The problem does not happen on ATI Radeon 7000
    with free drivers. This makes it an NVidia bug.

     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    Just to clarify: We *will* work around this in rdesktop, but
    NVidia should check their stuff.

     
  • Darkvater

    Darkvater - 2006-05-20

    Logged In: YES
    user_id=996227

    A (perhaps out-of-date) update to this problem.
    I have recently updated to OpenSUSE 10.1 that comes with
    xorg 6.9.0 and using the NVidia 1-0.8756 driver and I no
    longer need the
    export XLIB_SKIP_ARGB_VISUALS=1

    workaround even with Composite enabled.

     
  • Ilya Konstantinov

    Logged In: YES
    user_id=335423

    Since we no longer use RGBA visuals in any case, as far as
    we're concerned, this bug closed. However, you may still
    want to use older versions of rdesktop to reproduce this
    bug so it could be resolved within nVidia's drivers as
    well. When opportunity comes, I'll test nVidia's newest
    drivers as well and report their status here.

     
  • Ilya Konstantinov

    • status: open-accepted --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks