Bug 180301

Created attachment 124296 [details]
Differences in extramodes

I believe they were submitted to upstream, but didn't end up in the release
by the look of it.  Our modular X packages started out completely patch
free, and the only patches that have been added, are ones to fix bugs reported
during FC5testN and devel testing.  Any patches that were in our 6.8.x packages
were dropped.  We planned on reviewing them all during FC5 development and
re-including any ones still relevant that didn't get upstream yet.  I suspect
that we'll probably review that soon though.  Before test3 would be a good
idea, but definitely before final FC5.

Thanks for noticing this and reporting it.

It appears that /usr/share/rhpl/extramodes contains the modes too.  No idea
why that's there though.

I have updated xorg-x11-server with a forward port of the modelines
patch we applied to FC4/RHEL4/etc.  It'll be in build 1.0.1-6 and newer.

Note however that neither the FC4 or FC5 X sources have many of the modelines
that are in the diff you attached.  I'm not sure how your diff was created.

For example, none of these are in FC4:

-# 2560x1600 @ 60.00 Hz (GTF) hsync: 99.36 kHz; pclk: 348.16 MHz
-Modeline "2560x1600"  348.16  2560 2752 3032 3504  1600 1601 1604 1656  -HSync
+Vsync
-
-# 2560x1600 @ 70.00 Hz (GTF) hsync: 116.55 kHz; pclk: 410.26 MHz
-Modeline "2560x1600"  410.26  2560 2760 3040 3520  1600 1601 1604 1665  -HSync
+Vsync
-
-# 2560x1600 @ 75.00 Hz (GTF) hsync: 125.25 kHz; pclk: 442.88 MHz
-Modeline "2560x1600"  442.88  2560 2768 3048 3536  1600 1601 1604 1670  -HSync
+Vsync
-
-# 2560x1600 @ 85.00 Hz (GTF) hsync: 142.80 kHz; pclk: 507.23 MHz
-Modeline "2560x1600"  507.23  2560 2768 3056 3552  1600 1601 1604 1680  -HSync
+Vsync


I've CC'd jeremy and clumens (rhpl and rhpxl maintainers).  Guys, what is
the reason that rhpl ships its own custom extramodes file, and why is this
used at all?  Any extra modelines should be built into the X server
directly, so that it works for all users, not just those that choose a
path through rhpl.  Please submit modelines to xorg-x11-server in the
future so we can add them as needed.  Any other info you can give for
this would be appreciated.

Should I merge all of the rhpl extramodes into the X server now?

(In reply to comment #4)
> Note however that neither the FC4 or FC5 X sources have many of the modelines
> that are in the diff you attached.  I'm not sure how your diff was created.
> 
> For example, none of these are in FC4:

Correction:  My diff was against unpatched sources.  I decided to investigate
deeper after the last post, since it was so odd that I wasn't seeing what
you saw.  It turns out that somewhere along the line we ended up having
2 completely separate patches patching the extramodes file.  I wasn't aware
of the second one.

I'm going to integrate the two patches into a single patch now, and apply
it to FC5/FC4/RHEL4.


> I've CC'd jeremy and clumens (rhpl and rhpxl maintainers).  Guys, what is
> the reason that rhpl ships its own custom extramodes file, and why is this
> used at all?  Any extra modelines should be built into the X server
> directly, so that it works for all users, not just those that choose a
> path through rhpl.  Please submit modelines to xorg-x11-server in the
> future so we can add them as needed.  Any other info you can give for
> this would be appreciated.
> 
> Should I merge all of the rhpl extramodes into the X server now?

I'm still curious about this tho...

It was originally added by either alex or msf, iirc -- from a quick look at the
code, it's basically that we need to calculate in rhpxl/s-c-display if your
monitor supports a specific mode to determine whether it should be shown or not.

If we installed the file from the X server sources, we could drop it from rhpxl
and only have one place to update it.

(In reply to comment #6)
> It was originally added by either alex or msf, iirc -- from a quick look at the
> code, it's basically that we need to calculate in rhpxl/s-c-display if your
> monitor supports a specific mode to determine whether it should be shown or not.

Ah.

> If we installed the file from the X server sources, we could drop it from
> rhpxl and only have one place to update it.

That would make too much sense perhaps.  ;o)   On a serious note though,
since the file doesn't mean anything to the X server at runtime, if we
install it as part of the X server package, users may edit it, thinking
it will change the runtime behaviour of the X server perhaps, and file
"I edited the X server extramodes file, and restarted the server, and the
new modes didn't take effect" bugs in bugzilla.

I'd like to avoid that per se.  Including it in the SDK would work, except
we don't want software having runtime dependencies on the SDK, so rhpl would
then have to swipe a copy of it during package build from the installed SDK
package.  That's kindof ugly too I guess.

Perhaps installing it into /usr/share/xorg/extramodes with a huge comment
at the top indicating it is for use of rhpl would be sufficient enough
to avoid bug reports.

Opinions about the above appreciated.


I've commited the modes to my local packages, and they'll be present in
xorg-x11-server-1.0.1-6 when it hits rawhide.

Doing /usr/share/xorg/extramodes with a comment about it just being present for
tools to be able to calculate whether a monitor can support a given mode seems
sane to me.  vesamodes would probably also be good to drop in at the same time
(since rhpxl carries a copy of it also)

vesamodes and extramodes are now installed into /usr/share/xorg/ read-only,
with comments at the top to discourage people from trying to edit them.

xorg-x11-server-1.0.1-6

Setting status to "RAWHIDE"