Created attachment 41683 [details] test program Attached is a test program which attempts to stretch a two-pixel image horizontally using Cairo. It generates four files: r-image-24.png should be pixel-identical to r-xlib-24.png and r-image-32.png should be pixel-identical to r-xlib-32.png. On my system (I don't remember the exact marketing name of the card, but the driver identifies it as "NVIDIA NV94" and as "a NV50 generation card"), even with the very latest version of the Nouveau driver (xf86-video-nouveau git dc89dac734167bcbc667b39ca6ee2043871a60bf), the -xlib- files are not identical to their respective -image- files. (I will also attach the test results as produced by my system.) With the 24bpp image, the problem appears to be simply that Cairo's EXTEND_PAD (Render's RepeatPad) is not doing its job, despite that I do see code in the driver to implement that mode. The upscale is happening as if there were black pixels around the edges of the single-pixel source image, instead of green and white pixels as EXTEND_PAD specifies. With the 32bpp image, in addition to that problem, there are also garbage pixels at intervals. I am happy to provide more information as necessary and/or to test patches.
Created attachment 41684 [details] test output: r-image-24
Created attachment 41685 [details] test output: r-image-32
Created attachment 41686 [details] test output: r-xlib-24
Created attachment 41687 [details] test output: r-xlib-32
Created attachment 41688 [details] Xorg.log
Created attachment 41689 [details] dmesg
Forgot to mention: for the test program to actually test the behavior of the driver, I believe it is necessary to use libcairo 1.7.
It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report. In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one. Thanks, The Nouveau Team
It is user-hostile and unprofessional to mass-close bugs, even very old bugs, without making any attempt to reproduce the problem first. http://www.jwz.org/doc/cadt.html I'm willing to cut a *little* slack on this bug because it may have appeared to require specific hardware to reproduce; however, I went to the trouble of writing a self-contained test program and giving precise instructions for reproduction, so I expect you to at least *try* to find the appropriate hardware, and if you couldn't, to say so, instead of just "shrug, this might have been fixed." I would have been happy to test development drivers, even, if I had ever been asked. That said, with the latest software present in Debian unstable, the bug appears to have been fixed, so I will leave it closed.
(In reply to comment #9) > It is user-hostile and unprofessional to mass-close bugs, even very old > bugs, without making any attempt to reproduce the problem first. > http://www.jwz.org/doc/cadt.html I wasn't a big fan of it either (despite proposing it and doing it). But look at it from the project's standpoint -- volunteer based (and not exactly a big team), high code churn rate (esp 1-2 years ago), high hardware death(/replacement) rate, large variety of hardware, 400+ bugs deep, of which 200 are from more than 2 years without an update. So I didn't see a better way of getting a handle on the situation. Of the 200+ bugs I closed, about 10 have gotten follow-up comments of any sort (either that it's been fixed/hardware gone/still a problem). I'm individually pinging newer bugs, and I'm not having a great response rate either (but better). Besides, you always have the option of re-opening the same bug and providing updated information. As a bug filer, I think it's reasonable to expect you to be the main tester (at least with nouveau).
We must admit that for a bug reporter, he was top-notch! Too bad no-one took a look and then the bug got lost in our bugzilla, among 400+ other bugs. Although, the team must have concentrated on getting some features to work before addressing bugs. It is a very rationale approach in a reverse-engineering development environment. So, my sincere apologies, we are trying to make more case of bug reports now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.