Xorg testers needed

[bryceharrington]

The new radeonhd driver is uploaded to universe for anyone wishing to play with it. :-)

Today is beta-freeze, which means no further changes except for extremely critical bugs. While we certainly have some serious X bugs, I don't think we have any release critical ones. Thank you to everyone who has helped in this thread doing X testing for that, especially those who have been testing -ati lately; I think having the xrandr support for -ati is going to be a killer feature for Gutsy, and there's no way that could have happened if not for you.

Since this forum is described as Development (Gutsy Gibbon), I expect that once we start on Hardy we will need to start a new forum, but I'd like to get your guys' input on this. How well do you guys think this worked having one thread for Xorg testing; do you think we should do the same next time, break things up per-package, or...?

Hardy is a long term release candidate, and as such your testing work will be even more valuable. I'd like to see us grow this team larger, and get more folks involved. How do you think we should do this? What changes could we make that would both bring in more people, and help them be more effective? More frequent experimental package releases? Better debugging docs? Better test reporting tools? If you had to pick one thing to focus on, what would it be and why?

[Miguel]

Since this forum is described as Development (Gutsy Gibbon), I expect that once we start on Hardy we will need to start a new forum, but I'd like to get your guys' input on this. How well do you guys think this worked having one thread for Xorg testing; do you think we should do the same next time, break things up per-package, or...?

Being an LTS, I suspect the chances for noveau to make it will be slim. Thus, I think mantaining a master X.org thread might work. Else, if we have new ati, radeonhd, noveau, fglrx, nvidia and intel drivers the thread might get saturated fast. So maybe a master thread plus some driver threads for experimental packages might work. Just remember we are on the 26th page... with very little non-ati feedback.

Hardy is a long term release candidate, and as such your testing work will be even more valuable. I'd like to see us grow this team larger, and get more folks involved. How do you think we should do this? What changes could we make that would both bring in more people, and help them be more effective? More frequent experimental package releases? Better debugging docs? Better test reporting tools? If you had to pick one thing to focus on, what would it be and why?

If I had to choose something, it would be a test report tool. A wiki similar to what we had for the quick X.org test could do the trick. It would be nice to discard the placebo effect and have more accurate reports about where each driver fails. On the other hand, I don't think more frequent testing packages releas would help. I fear this might lead to having a few reports of very different configs. I found gutsy's releases to be OK, although it's the first time I've done some serious testing for a distro.

[hanover.fiste]

I would tend to second the test reporting tools. Something else to think about might be automated test scripts, to make the tests more consistent and make it easier for people to participate.

[u.b.u.n.t.u]

I would tend to second the test reporting tools. Something else to think about might be automated test scripts, to make the tests more consistent and make it easier for people to participate.

This idea has a lot of merit, much self evident, such as standardization.

[u.b.u.n.t.u]

Thank you to everyone who has helped in this thread doing X testing for that, especially those who have been testing -ati lately;


Good on you too Bryce, for taking on the challenge of the second most important bug, rolling up your sleeves and welcoming others to help work on it.

[bryceharrington]

Excellent, I agree testing tools will be a good choice for the LTS release.

I've got some really basic tools I started developing earlier on before the patch work started getting hot and heavy. I'll plan on polishing them up for us to use within the next month. Meanwhile, does anyone have suggestions for what to test, or scripts that can be used to test features?

Bryce

[yelo3]

I think that some important things to test are about the performance:
1) 2d performance without compiz, especially in firefox, which has some very slow rendering now
2) the same performance, but with compiz enabled (and the script could get the fps from the benchmark plugin)
3) the same performance under havy cpu and hdd load with and without compiz
4) check the fps in some simple and complex games, and maybe also google earth: I think that lots of people are using it more than games!

these tests are only about the performance, of course it is not the most important part, but I think that most of the times it is forgotten. In my opinion if a thing works but with very low performance it is the same as it does not work.
What do you think?

[yelo3]

I have a question:
the firefox scrolling bug (huggish scroll in sites with a static background image) is really bothering me
do you think it is a firefox problem or a X/driver problem?

I'd like to point some developer to it, so it gets assigned. So please, can every of you who have (and have not) this issue add a comment to https://bugs.launchpad.net/firefox/+bug/125970 ?
Thank you in advance

[zasf]

Thank you to everyone who has helped in this thread doing X testing for that, especially those who have been testing -ati lately;

[cut]

I'd like to see us grow this team larger, and get more folks involved. How do you think we should do this? What changes could we make that would both bring in more people, and help them be more effective? More frequent experimental package releases? Better debugging docs? Better test reporting tools? If you had to pick one thing to focus on, what would it be and why?

I think that the "dev link forum" is a great idea.

You could easily create a launchpad team so that people get involved and are grouped together. The forum is quite dispersive, so I think having a lp would help people get together.

Another fundamental thing is having packages in .deb files ready for testing. This is essential. I had problems with my ati card, so I opened a bug on freedesktop bugzilla, the dev asked me to test master git code, it was not as straightforward as installing a deb file (dl git, install -dev packages, make, install, etc), most of the people would just have given up.

As others already said, a reporting tool would be fanstastic as well, something like apport which creates a report with all the relevant files for you.

These steps would make testing and reporting very straightforward.

Thanks bryce,
Matteo

[alex_mayorga]

Hello everyone,

I feel I've got bite by a bugger on the "bullet proof X", my video driver or something else (I'm pretty much a n00b, so please pardon my ignorance).

I run Gutsy on a Dell Inspiron 8200 (that if I'm not mistaken runs a NVIDIA GeForce4 Go 440) and it used to run just fine until a couple of updates in the past 2-3 days.

The symptom I saw at first was that I saw the screen that tries to recover X, even tough it was running just fine using nv before that. After some flickering it lets me log in, but it has degraded my video to 800*600. Once I log I try to change the card on the GUI, but on every reboot I'm back at 800*600.

Can somebody help or point me on the right direction please?

Thanks in advance,
Alex

[mabovo]

This can be related to this http://ubuntuforums.org/showthread.php?t=558449 or this http://ubuntuforums.org/showthread.php?t=552699, but feel free to fill a bug report on launchpad

[alex_mayorga]

This can be related to this http://ubuntuforums.org/showthread.php?t=558449 or this http://ubuntuforums.org/showthread.php?t=552699, but feel free to fill a bug report on launchpad

Thanks on the pointers, in the mean time a fellow ubuntero has filed https://bugs.launchpad.net/ubuntu/+bug/144525 for this, if anyone can throw some light on it. I'll try the suggested fixes once I get home.

[hanover.fiste]

Excellent, I agree testing tools will be a good choice for the LTS release.

I've got some really basic tools I started developing earlier on before the patch work started getting hot and heavy. I'll plan on polishing them up for us to use within the next month. Meanwhile, does anyone have suggestions for what to test, or scripts that can be used to test features?

Bryce

Automated scripts would be ideal, but I'm not sure how much could actually be scripted. It may have to be a series of tests to be run, with specific things to record, such as how long it takes to scroll down a specific page in firefox, or specific things to look for in rendering certain fonts at various sizes. I think we need to try brainstorming on that aspect and see what ideas we can come up with.

[bryceharrington]

Hi all,

Like most of the other devs I've been completely preoccupied by bug hunting the past week, so apologies for my absence here.

The good news is I've got a bunch of fixes queued up, including:

127008 - On intel laptops, the display gets corrupted with colored squares when doing the Alternate Installation CD. Turned out that this was because of some weird vga16fb incompatibility when doing xprobe.sh. Don't know exactly why it didn't work, but albert and I found that for these systems ddcprobe.sh would detect the resolution just as well, but didn't trigger the bug.

27667 - this was a really long standing bug that affected a lot of people. When installing on a LCD, frequently X would get configured to use a resolution one level below what it should. The reason for this was that xresprobe was designed to toss the highest resolution, because on certain CRTs it was hard to read. Unfortunately xresprobe sometimes mistakenly identifies some LCDs as CRTs when they have analog connections (I guess this means VGA as opposed to DVI?) So tons and tons of people were finding Ubuntu misconfigures the resolution of their LCDs. Looking at the CRT logic, kees and I found 3 other logic errors as well. We both agreed that the code had to go; xresprobe is a low level tool and shouldn't be censoring resolutions like this, and besides LCDs are a lot more common than when xresprobe was first created, so this particular issue is a lot more common now.

144956 - this one was my fault; one of the fedora patches I pulled into xserver 12ubuntu4 to fix a (probably rare) corner case with Preferred Modes was causing the resolution to get mis-detected. seb128 helped narrow this one down; I've put the patch in question on the chopping block.

And probably a few others less notable.

yelo3, yes I think performance tests are a great idea. One thing though, we will need to have a reliable way of measuring performance; do you think this is something you can investigate? I imagine that while scrolling speed in firefox is quite noticeable as a human, it may be tricky to measure programmatically. Can you investigate with the firefox folks if there is a way to either measure this directly, or to simulate it through some other tool? They may even have a performance test we could just appropriate. :-)

With games, I think measuring fps is going to be pretty straightforward, but you could experiment and see which ones give it in a way that can be measured easily through a simple script.

For the slow firefox scrolling problem, I would suggest starting by talking with firefox developers and get their comments on it. If it is an X-related thing, they may be able to give more specific details about why it's X, and what aspects of X should be adjusted for giving better results. Then we can take that info to Xorg to try improving things.

Matteo, that's not a bad idea to set up an X team in Launchpad. There actually is one, X-Swat, but it's very underutilized. Initially it was set up for being a team for people who work on bugs in Xorg. Do you guys think that'd be an appropriate team for us? I think I can add people to it if so. Otherwise, what would you prefer this team to be called? I can take care of setting it up. It will be useful for giving people permission to the code repository for the test tools, if nothing else. :-)

Alex, odd, but not unexpected that bulletproof-x might cause trouble. This forum is more for testing discussion than bug troubleshooting, so I'll follow up with you on 144525 tomorrow. Thanks for pointing to the bug ID.

Hanover, yes I agree that automating the steps may be a challenge. However, from past experience testing in other projects, you'd be surprised how often you actually can measure something programmatically, or at least simulate it. But you're right that initially we should consider a hybrid approach, doing the test steps manually until we find ways of automating them. That's the direction I figured we could take with the QuickCheck test (thanks for everyone that's filed these; I do promise to follow up, once a lot of this bug fixing work is out of the way.)

[yelo3]

Hi all,
144956 - this one was my fault; one of the fedora patches I pulled into xserver 12ubuntu4 to fix a (probably rare) corner case with Preferred Modes was causing the resolution to get mis-detected. seb128 helped narrow this one down; I've put the patch in question on the chopping block.


great! might this be the problem of this bug? https://bugs.launchpad.net/bugs/137626


yelo3, yes I think performance tests are a great idea. One thing though, we will need to have a reliable way of measuring performance; do you think this is something you can investigate? I imagine that while scrolling speed in firefox is quite noticeable as a human, it may be tricky to measure programmatically. Can you investigate with the firefox folks if there is a way to either measure this directly, or to simulate it through some other tool? They may even have a performance test we could just appropriate. :-)

With games, I think measuring fps is going to be pretty straightforward, but you could experiment and see which ones give it in a way that can be measured easily through a simple script.

For the slow firefox scrolling problem, I would suggest starting by talking with firefox developers and get their comments on it. If it is an X-related thing, they may be able to give more specific details about why it's X, and what aspects of X should be adjusted for giving better results. Then we can take that info to Xorg to try improving things.

If I'm not wrong, at least compiz can print fps on the console after enabling the benchmark plugin with the terminal output option enabled.
About firefox, I'd really like to talk to a firefox developer, but really upstream and launchpad are not responding to my bugs. I've also tried the upstream firefox mailing list without responses. What can I do? Do you have the "power" to extabilish a connection between me and a firefox developer?

[bryceharrington]

yelo3, unfortunately I don't have contacts within firefox. Often in large communities like firefox you have to earn some "sweat equity" before the devs will pay attention; for example, helping address other user's questions for a while, assisting with bug triage, providing interesting and useful test results, or contributing docs or something.

As to bug 137626 with -ati, no it looks like it's completely different from the other bugs I mentioned. (Also, 144965 is only affecting -intel.) In fact, it's not certain that 137626 is actually a bug since the issue is that it's providing all available resolutions rather than filtering down to the "appropriate" ones.

[jbernardo]

Bryce,
I have to retract my previous posting - I still need to "roll my own" xorg-server without patch 120. I found out that adept isn't updating xorg-server for me as I added "-jbs1" to the changelog revision when I removed that patch and built it, so I had not tested the latest xorg-server.
I am also seeing now the resume problems many people have complained about with the intel driver, which I hadn't tested also before, as I would most times just shut down my laptop.

[Miguel]

Hi all,

If one were to measure FPS in a game, I suppose the best way would be to choose a game with an easy benchmarking (Quake engine based, for example) and then create a demo and a config file that everyoe could run. This should be easy to do in games such as Doom 3, Quake 3 and 4 and based on them. The good thing is that, as ID release the source code as gpl, free games such as Nexuiz, OpenArena and Tremulous should be easy to benchmark. Choosing one should be enough for informative purposes.[1]

More thorough testing, taking into mind different 3D engines and different type of games would require specialised tools such as FRAPS (a known tool for measuring FPS in Windows) or even some loggers for a single game (Oblivion comes to mind). In any case, this would be overkill, beccause I don't think we have either the necessity of extremely accurate benchmarks[2] or the time to perform such dedicated tests in a rapidly changing scenario[3]

Notes:
[1] An X.org developer stated in Phoronix that they were not going to use dirty hacks in the drivers to improve FPS in one single instance, so I suppose that performance improvements will probably be apparent in all scenarios.

[2] Is a 5% difference relevant?? In a game?? I know I'd go mad if my DFT calculations took 5% more than they should but I earn my life with them.

[3] If one is changing the base system (kernel, libs, mesa, X server, X driver) often the system might change quicker than the time needed to perform the required benchmarking.

PS: It might be interesting to contact Phoronix' Michael Larabel regarding benchcmarking, at least to exchange views with a guy experienced in benchmarking games under linux.

[gregh]

Card: ATI X1300
Setup: Dual screen

Using the gtk config tool does not allow this to be setup in dual screen mode.
In the hardware tool I cam see the graphics card properly detected, but the "screens and graphics" config utility crashes if I try to setup the second screen.

Is there a bug reporting area in launchpad for this tool? I could not find a suitable are when i went to look.

Thanks,

Greg

[Ub1476]

Hi I'm using..

ATI Radeon Mobility X1400
Gutsy Gibbon live cd (tribe 5)

X fails to start after "Loading Gnome Display". After that I get a black screen, which will lead me to the X error after pressing Enter. The annoying thing though, is that I can't enter the terminal after closing the error windows.

I think the reason X won't work on my card was that it didn't try to add this in the Monitor section:

Section "Monitor"
Identifier "Generic Monitor"
Option "DPMS"
Horizsync 36-52
Vertrefresh 36-60
EndSection

Because when I installed Feisty, X wouldn't start without adding the Horissync and Vertrefresh values, even though I used a low resolution.

Hope this will be fixed;)

[Ub1476]

Alright I entered the terminal by pressing ctrl+alt+f1. Then I opened the xorg.conf file and found this..:

Section "Monitor"
Identifier "Generic Monitor"
Option "DPMS"
Horizsync 30-70
Vertrefresh 50-160
EndSection

Subsection "Display"
Identifier "Default Screen"
Device "Generic Video Card"
Monitor "Generic Monitor"
Defaultdepth 24
EndSection

There are 3 problems there. Both values of the Horizsync and Vertrefresh (look at my above post for what works), and the fact that there's no Display subsection where this should be added:

SubSection "Display"
Depth 24
Modes "640x480"
EndSubSection

Overall here's what worked for me after editing:

Section "Monitor"
Identifier "Generic Monitor"
Option "DPMS"
Horizsync 36-52
Vertrefresh 36-60
EndSection

Section "Screen"
Identifier "Default Screen"
Device "Generic Video Card"
Monitor "Generic Monitor"
Defaultdepth 24
SubSection "Display"
Depth 24
Modes "640x480"
EndSubSection
EndSection

sudo killall gdm
sudo gdm

[Tjarn]

Bryce -- Poking around it looks like this area might be the cause of my problems in working with Gutsy. I submitted a bug --#152678 -- and my apologies for being a little sarcastic in the report.

Basically whatever is rewriting the xorg.conf file is breaking my setup badly. The first thing is that it totally ignores the 'virtual' keyword, the second is that it destroys the additional color depth settings. Here's what I have to do to work around.

1. Go into /etc/X11 and
$ sudo rm xorg.*

2. Copy a working xorg.conf from my Feisty setup

$sudo cp /Feisty/etc/X11/xorg.conf .

3. Blow away this instance of X
<ctl><alt><backspace>

4 Login agin and run the display confuguration tool. It will show 1600x1200 as a possible selection. Selecting it works fine -- I have a nice 1024x768 window into a 1600x1200 desktop that moves nicely with the mouse pointer.

However -- when I reboot, it gets totally trashed, so I have to reconfigure the whole thing each time I boot. This is incredibly annoying, and does tend to make for a less than polite attitude sometimes. I apologize in advance if I get less than polite after a couple times of doing this.

[myk.dinis]

I'm having a similar problem as the above user...

I had my video setup perfectly after completely upgrading my hardware...

Took a good number of hours but I got it running
ATI x700 using the fglrx by ATI using bigdesktop
everything was running fine...so I decided I should upgrade to gutsy...

BAH! Now everytime I reboot I lose all my work...

My xorg.conf is setup exactly as I need it but something keeps trying to modify my resolution and never look at my xorg.conf for input....

gah...Any idea what i can do? Is there some init file I can change to be sure it looks at my xorg?

Or if nothing else...can I do a downgrade back to feisty?

Thanks!
myk