Bug 351627

I would like to see this implemented for Alpha 1 (Jan 17), so it needs to be done this week. Otherwise I'm afraid we won't see radeonhd driver in our product before Alpha 3 (March 18).

I have created a set of patches, that should implement this feature. However, despite my efforts SaX doesn't include the "monitor-<secondard_output>" "EXT" option to the xorg.conf. The profile is called, and it actually tries to set this option (there's a print STDERR included), but somehow this is lost.

Marcus, I'm pretty much lost here, could you take a look? Other than that the changes should be all that's needed.


Attaching both patches now, the first one against the C code, the second includes the profiles.

Created attachment 191859 [details]
Patch in SaX core

Created attachment 191860 [details]
Profile patch for radeonhd

Thanks for the patches. Matthias, writing profiles is a real pita, isn't it :-)
I found one code point which has not been patched for radeonhd. api/monitor.cpp
(GUI) deletes/re-adds the monitor-* specs when someone deactivates/activates
dualhead. The re-adding happens for intel only because it was our only randr
based driver up to now. I have adapted the code there too

* will checkin the patches now and submit a package, could you double check ?
* sax2 also has been ported to qt4 now and so there is a big change together
  with the readeonhd adaptions. I hope I didn't opened up too many bugs

Thanks

Unfortunately the implementation doesn't work for me. When configuring a dualhead setup (two monitors side-by-side) xorg.conf is not written at all. :-(

Marcus, will you find some time to look at this, if I install a machine, on which you can test this (need my machine for working)? Otherwise we need to wait for Matthias until he's back.

this is not related to the fix mentioned here. See bug #351627
sax2 is not working at all due to the qt4 port

sorry I mean bug: #354386

Thanks. I gave it a try. Problems I encountered:

- For the first monitor I can only select between 800x600 and 1024x768
  (instead of required 1680x1050). 
- Although I selected side-by-side mode I got clone mode.
- I see wrong entries in xorg.conf
  ' Modes      "1024x7681024x768" "800x600" '

(In reply to comment #12 from Stefan Dirsch)
> Thanks. I gave it a try. Problems I encountered:
> 
> - For the first monitor I can only select between 800x600 and 1024x768
>   (instead of required 1680x1050).

Seems to be a general problem since switching to Qt4. Marcus will investigate.


> - Although I selected side-by-side mode I got clone mode.
> - I see wrong entries in xorg.conf
>   ' Modes      "1024x7681024x768" "800x600" '

I was still using an older SaX2 version. With the latest version a correct
configuration is created by SaX2. Still the driver thinks it needs to do
clone mode.

  (EE) RADEONHD(0): Cannot position output DVI-I_2/digital relative to output
  Monitor[0] without modes

Matthias need to look into this when he's back.

> Seems to be a general problem since switching to Qt4. Marcus will investigate

fixed in latest submission

Thanks. Resolution problem is fixed now. But now SaX2 generates strange Modes lines in xorg.conf (again). :-(

  SubSection "Display"
    Depth      24
    Modes      "1680x10501680x1050" "1680x10501680x10501680x1050" [...]

This also happens when creating a single head configuration.

Tried again with current SaX2 of STABLE. I'll attach the complete xorg.conf.

[...]
Section "Monitor"
  Option       "CalcAlgorithm" "XServerPool"
  DisplaySize  433866 271271
  HorizSync    30-66
  Identifier   "Monitor[0]"
  ModelName    "200W (DIGITAL)"
  Option       "DPMS"
  VendorName   "PHILIPS"
  VertRefresh  30-61
  UseModes     "Modes[0]"
EndSection
[...]
Section "Device"
  BoardName    "FireGL V3300"
  BusID        "1:0:0"
  Driver       "radeonhd"
  Identifier   "Device[0]"
  Option       "SaXDualHead"
  Option       "monitor-DVI-I_2/digital" "EXT"
  VendorName   "ATI"
EndSection

DisplaySize is wrong and results in a Xserver crash. The second monitor section for "EXT" is missing completely. :-(

Created attachment 195738 [details]
xorg.conf

Current sax2, after upgrading libqt* and sax*:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid


Seems like I'll have to upgrade the full system first...

I'm not sure if this will help. I've seen this before with a fully upgraded system. :-(

Even worse:

gkar:/suse/mhopf # sax2 -r -a
SaX: initializing please wait...
SaX: your current configuration will not be read in

SaX: no X-Server is running
SaX: will start own server if needed

SaX: something went wrong while X was called with -probeonly
SaX: try to call 'sax2 -p' and select a single device ?
abort


There's no Xserver running, I deleted all left-over locks and sockets. /var/log/SaX.log doesn't give me a single hint. Last line after sysp detection is

05-Mar 19:17:31 <I> Sysp: XStuff detection data


X -probeonly works fine.

gkar is running ATM, if you want to try. I'll just switch of the monitor.

I guess sysp -s xstuff crashes with segfault. I guess a duplicate of #367457
could you verify ?

Bug #367457 has been closed as fixed. So what should we verify? Update hwinfo?

yes latest hwinfo and test if sysp -s xstuff crashes or not

Thanks. Matthias, the one in /work/src/done/STABLE/hwinfo.

Yes, sysp -s xstuff segfaults. Compiling STABLE hwinfo, stay tuned.

sysp segfaults even with the hwinfo that has been submitted to stable.

To be verified on gkar.

rpm -q --changelog hwinfo:

* Thu Mar 06 2008 snwint@suse.de
- fix compilation on x86_64

* Thu Mar 06 2008 snwint@suse.de
- try a bit harder to find matching card for an interface (bnc #356405)
- fix segfault in new mouse code (bnc #367457)

sigh. sysp only segfaults if I sudo it - Stefan doesn't have this issue, so
sysp is apparently highly environment dependent.

Running after logging in as root does work. Oh well.

that's what I have found too. installing debuginfo package now

Hmm, I have installed latest sax2 from stable and the problem is gone

   sudo /usr/sbin/sysp -s xstuff

works now... don't ask me why ??

Ok, the multimonitor configuration is completely broken - SaX notices this himself with the following error report:

SaX library: Success
X configuration: Parse error on line 180 of section Monitor in the file /var/lib/sax/xorg.conf: This section must have an identifier line.


Section "Monitor"
  DisplaySize  380 290
  HorizSync    27-110
  Identifier   "Monitor[0]"
  ModelName    "VISION MASTER PRO 450"
  Option       "DPMS"
  VendorName   "IIYAMA"
  VertRefresh  50-150
  UseModes     "Modes[0]"
EndSection

Section "Modes"
  Identifier   "Modes[0]"
[...]
EndSection

[...]
Section "Device"
  BoardName    "Radeon X1550 64-bit"
  BusID        "1:0:0"
  Driver       "radeonhd"
  Identifier   "Device[0]"
  Option       "SaXDualHead"
  Option       "SaXExternal" "VertRefresh&50-60"
  VendorName   "ATI"
EndSection

Section "Monitor"
  VertRefresh  50-60
EndSection

sysp issue is now known and (almost :) fixed.

(In reply to comment #31 from Matthias Hopf)
> Ok, the multimonitor configuration is completely broken - SaX notices this
> himself with the following error report:

Exactly the same issue on intel.

could you bring gkar only again ?
thanks

* the sudo / sysp problem is fixed. wrong usage of sprintf
* the sax2 -a -b MergedFB problem if no DDC[2] information is available
  is also fixed. Profile.pm wrong ddc check

remaining problems:

* remote GUI tests are a pita
* I need gkar in a state where randr provides more than one channel as
  connected to test if dualhead setup in principal works

Matthias can you check that ?

Thanks

Marcus, the machine is now booted with the radeon card. radeonhd driver is installed and working. I also attached my 2nd DFP to the DVI-I port (via analog).

Interestingly, hwinfo --monitor only detects this second monitor now. So everything should be set up now.

I handcrafted a xorg.conf.2monitors, which shows that the EDID data of both monitors can be retrieved by the Xserver. This can also be used as a reference configuration.

I let an Xserver run on :0, so DPMS can actually kick in. I don't know whether this works correctly with the console...

ok according to our telephone call the non-gui parts works again.
I have added the PreferredMode setup for the standard Monitor section
and will submit a package now.

I'm 100% sure there are still problems with the GUI
Matthias I hand over this one to you again for inspection of the GUI
problems as soon as sax has built

thanks

Thanks, Marcus, just drop me a mail when the build is finished :)

Ok, testing:

1) sysp - s xstuff still segfaults if run in a NFS directory (root=nobody).
2) sax2 -r -b MergedFB works fine, and creates a nice configuration file.
3) sax2 GUI just loading the created config and saving again creates a broken
   config like in comment #31.
4) sax2 -r GUI with just saving (single head) seems to work fine. PreferredMode
   is apparently set correctly as well.
5) sax2 -r GUI with just activating dual head fails like in comment #31.

So clearly the GUI needs some love, so does sysp :-]

1) updated hwinfo source, local source doesn't had the bios fix in it
3) I found several bugs due to this great qt3to4 program and fixed them
   You can be sure there will be other GUI problems which we still did
   not found yet :(

submitted a sax2 package to stable and BS. Would you mind to test it again ?

Thanks

Unfortunately Matthias already called it a day. So testing needs to wait until monday. :-(

Looks good :)

Apparently, everything works now.

The sax information windows still stick in the upper left corner, and some texts there aren't wrapped around, but the configuration works fine.

For me this is fixed :)

*puh* good news. Thanks for testing.

the info window problem and the problem that no message text gets wrapped
correctly anymore is a bug due to the qt4 port. There is already a bug
open but Tom Patzig seems not to work anymore on this issue
will ask Kulow how to proceed

*** Bug 382592 has been marked as a duplicate of this bug. ***