add optional libXfont2 support

[stefan11111]

Same PR as #13 ,but everything squashed in one single commit.

[stefan11111]

@clbr@rofl0r
Any other concerns I should address?

[rofl0r]

using the header, the diff is much cleaner now, except that you suddenly changed the fpe type so now we have . vs -> accessing the field, which makes it a bit of a mess again.

[stefan11111]

using the header, the diff is much cleaner now, except that you suddenly changed the fpe type so now we have . vs -> accessing the field, which makes it a bit of a mess again.

@rofl0r The reason I did that is because of how libXfont2 handles the fpe functions.

I based this libXfont2 port on Xorg code, specifically this patch: https://lists.freedesktop.org/archives/xorg-devel/2016-May/049769.html

I tried to see if I can somehow make fpe_functions a regular pointer instead of an indirect pointer, but I couldn't. If you see some way to do that that I missed, let me know an I'll try to update my patch.

I changed all the accesses to indirect accesses so that I don't have ifdef's for libXfont1 direct accesses vs libXfont2 indirect accesses.

I am pretty sure the compiler optimizes out the indirect accesses in the libXfont1 case, but I could use
'_X_EXPORT FPEFunctions ** const fpe_functions = &_fpe_functions;' to help it a bit.
In any case, the overhead is very small for direct vs pointer access, way smaller that the actual call.

[stefan11111]

@Rofl0l Fixed the 2 things you pointed out and added the const I mentioned in my above comment.

I can get rid of one more ifdef in dix/main.c with something like '#define ResetFontPrivateIndex(...)', an empty function define to remove a call that doesn't happen with libXfont2. Should I do that too?

[rofl0r]

i'm just providing some advice on how i would do things to make them less awful :)
though i have no idea what the maintainers think about the whole thing, and they're the people that have to say yay or nay. if i was the maintainer, i'd be inclined to merge it if the ugliness can be kept to a minimum.

[stefan11111]

@rofl0r I added the empty function define too.
My concern with using the preprocessor is to not obfuscate things. That's why I ask what approach I should take with this. Should it be desired, I can add something like '#define FOO_C_INSIDE' for every file I put an ifdef in, and that would allow me to move everything about the libXfont version switch to the header. I think going that far would be too much obfuscation, but I can do that if it's desired.

Btw, are you not a tinyx or tinycorelinux dev? I assumed you were since I saw you comment in various issues and PR's.

[rofl0r]

nope, @sabotage-linux dev here.

[stefan11111]

@clbr
ping

[clbr]

Sorry, can't review right now.

[narinishi]

@stefan11111 TrueType fonts don't work.

I tried modifying dixfonts.c to not remove my truetype folder from the font path list, and ended up with this cryptic error:

[stefan11111]

@stefan11111 TrueType fonts don't work.

I tried modifying dixfonts.c to not remove my truetype folder from the font path list, and ended up with this cryptic error:

How did you modify dixfonts.c ?
Do you have a setup where you can use both libXfont1 and libXfont2?
If so, is this also a problem with libXfont1?

[narinishi]

@stefan11111

Around where it says "Could not init font path element %s, removing from list!\n", I just made it not remove the path.

I used current Debian, which only has libXfont2. The DEFAULT_FONT_PATH in TinyX source doesn't add the truetype path by default, so I'm not sure TrueType support was ever tested.

Perhaps I am not taking the correct approach.

To test TTF support, you can install stterm (st) and fonts-dejavu (font-dejavu or dejavu-fonts-ttf). Then run st -f "DejaVu Sans Mono" and compare if the @ symbol looks different than when running st without arguments. Note, if the font is not loaded, it may fall back to a non-monospace font, which will have visibly uneven letter spacing.

Best of luck.

[stefan11111]

@stefan11111

Around where it says "Could not init font path element %s, removing from list!\n", I just made it not remove the path.

That code is there to prevent crashes like yours.
The proper fix is not to remove that code, but to see what fails and calls that code.
I may look into it, but likely not in the near future.
If you do look into it, make sure you don't break something for the libXfont1 case.

[stefan11111]

@clbr ping

[stefan11111]

@clbr ping

[stefan11111]

@clbr ping

[stefan11111]

@clbr ping