X in FC7

Adam Jackson ajackson at redhat.com
Mon Nov 13 13:17:28 UTC 2006


Jesse Barnes wrote:

> Well, I created an account but can't seem to edit the page.  Anyway, I 
> like the idea of getting rid of xfs, it seems fairly useless.  And to 
> quote mharris from awhile back:
> 
>> Long term, what would be really nice, is if someone figured
>> out a way to implement core fonts using fontconfig/Xft
>> underneath so we have one font system, and it provides
>> legacy compatibility to ancient applications that have not
>> been updated to modern interfaces.  That is something that
>> would need to be spearheaded at the X.Org level rather than
>> at a specific distribution however.

So here's where I start to admit some font ignorance, but.  I took a 
hack at this a while back, and it seemed to me like using fontconfig for 
matching was the wrong idea, since the properties available from 
fontconfig didn't quite match what you can select on with XLFD.

As said on the wiki page, what problem is xfs trying to solve?  If it's 
just about the ability to add fonts at runtime without having to do 
'xset fp rehash', then that should be a very small amount of code to add 
to the X server.  You need to watch for directories popping in and out 
of existance, but, okay, we know how to do that.

> That said, which apps care about core fonts these days?  Would it make 
> sense to just build-in a fixed font or something and let everything 
> else use fontconfig (as most decent apps do these days)?

We do actually have a built-in fixed font now.  And cursor.  They've 
always been in the modular libXfont, we were just never telling the 
server to use them.  In FC6 they're enabled by default.

You can not remove core font functionality though, for the same reason 
you can't remove dashed wide arcs.

> Also, which input drivers should we be using?  Isn't synaptics much 
> better for laptops than the default mouse driver?  What about evdev?  
> Should it be the default?

We already detect synaptics via some anaconda voodoo.

evdev should probably become the default once the input hotplug branch 
lands upstream and we start shipping that server; that's likely to be 
xserver 1.3, so that might not be ready in time for Fedora 7.

That's sort of the pink elephant here.  1.3 will have a lot of really 
good stuff merged, but it's likely to be broken, guaranteedly for closed 
drivers but also internally.  I'm hoping we can get dist-{hg,git} going 
soon so I can make packages available for both, 1.3 for the adventurous 
and 1.2 for the sane.  Yes it's doable with CVS, but that's far more 
pain than I'm willing to take.

Thanks all for the feedback, keep it coming.

- ajax




More information about the fedora-devel-list mailing list