X.Org Could Use More Help Improving & Addressing Its Security

[billyswong]

i'm pretty sure wayland has better multi-head support than x11

I was giving very specific cases. One of them is "subpixel AA and font hinting for text". Can Wayland apply them correctly in mixed DPI environment now? No, we cannot. X11 is old and it is reasonable for it to have zero support of mixed DPI. Wayland should have designed to support this specific case in day 1. But no, we still can't do it. Worse, most Wayland maintainers and fanboys refuse to admit it is a problem.

[oiaohm]

The article you linked to tells a different story to me, unlike your interpretation. What FreeType v40 bypassing is patented subpixel hinting (grid-fitting). FreeType still need to know the monitor orientation to apply subpixel AA and hinting to their corresponding direction. In standard subpixel order, left edge pixel is blueish and right edge pixel is redish. When a monitor is flipped upside down, the left edge pixel now shall be redish and right edge pixel shall be blueish. In standard orientation hinting is only done vertically while a 90 degree rotated screen will do hinting horizontally.

freetype uses grey scale /flat color AA by default and did not have subpixel AA for a very long time. So none of the redish/blueish stuff that requires a multi colour AA/subpixel usage for this problem.
http://wp.xin.at/archives/4702 yes the greyscale AA is noted here.
Yes people have attempted bring greyscale AA to windows because you avoid this redish/blueish issue by not using multi color AA in the first place.

“Greyscale font Anti-aliasing” is something that is different to windows. Greyscale font Anti-aliasing come out of patent avoidance by freetype but then resulted in bugger me moment this is just as good on screen as the patented options with none of the draw backs for fonts once you cross a particular DPI level. Using greyscale font anti-aliasing you don't need to know the corresponding direction of the monitor because this form of AA does not need to know "subpixel color order" because all colours in a pixel are being adjusted unified(yes simpler processing as well). Windows standard font AA does process all the colour channel individually this does require you to know monitor orientation.

Yes the general Linux font AA is greyscale AA not multi color AA/subpixel AA.

https://forums.macrumors.com/threads/the-subpixel-aa-debacle-and-font-rendering.2184484/post-28912005

Yes apple default is greyscale AA, Android default is greyscale AA. Yes that apple compare there where the person thinking the difference is subpixel 95% of the difference is not subpixel but gamma valve.

https://forums.macrumors.com/threads/the-subpixel-aa-debacle-and-font-rendering.2184484/page-10?post=29429586#post-29429586

Turns out greyscale AA can be very good on modern screens with modern DPI levels .

Yes greyscale AA there is not using subpixel hinting in the second link either. Greyscale AA + modern font rendering methods does a really good job without using the subpixel stuff.

Linux out the box distributions reality don't have subpixel AA turned on in freetype. So the majority of your Linux applications don't need to know monitor orientation. If you are going to be software up-scaling the application output window again you most likely want the application to use Greyscale AA. Then if required apply subpixel AA after the output has been up-scaled.

billyswong greyscale AA on fonts is a lot more common than people would think. Yes as the DPI goes up and the methods todo greyscale AA font stuff with good hinting the reasons for subpixel font hinting and AA going away. Yes with HiDPI screens being able to not tell application screen orientation comes important so application can be upscaled well because it does not subpixel render because that information is missing.

No objection to the need of lying for legacy software. We are going to convert legacy software from SDR bitmap to HDR bitmap in compositor side for HDR monitors already.

With X11 there is a need because the applications will request detailed monitor information that will include information that causes them todo something stupid.

(A) subpixel color order / orientation and (B) the "DPI" or more accurately the intended scaling factor.

The point A here does not apply to fonts on Linux that much due to how much grey-scale AA is used. Game AA or some graphical software AA maybe but not font AA for the majority because of the common default freetype AA being greyscale AA.

B being DPI not so much. Scaling factor I would say is important. Think the case a person with poor version DPI of the monitor may not be the DPI you want the application to know. You may want a application to think its on hiDPI monitor when it really on a standard DPI monitor so it shown over scale to user without really scaling it.

Really you want the application to believe the screen/monitor DPI is what ever the user wish the application to believe it is. So fake not the real monitor DPI unless the user wants the application to know the real monitor dpi. This requires a different method to collect data from hardware and just give it to the application as X11 uses.

[pal666]

A proper multi-head support

i'm pretty sure wayland has better multi-head support than x11

[pal666]

while in Wayland whole window is application managed area and your application will get input event, not some DE/WM system event.

so, in wayland your windows react to clicks on window buttons and elsewhere as needed or not?

[pal666]

I see two main disadvantages:
1) each framework draws a different window decoration; but this is only an aesthetic problem

but somehow you fail to see that each framework draws a different window interior? let your frameworks use common library with proper plugins to draw window decoration if you like your decorations to not match your interiors

The most complex part of my sentence was "raise on click on the title bar": how the compositor implements this if it doesn't know anything about the "title bar" due to CSD ?

why do you even think about it? is it your job to write wayland code? why you don't leave it to people who do it? csd doesn't mean "compositor doesn't know", it means "compositor doesn't draw".

[pal666]

I think the error wasn't not providing an equivalent of X11, but not providing all the pieces for it.

not providing pieces for implementing print server? why do you think such nonsense? wayland has to provide only important things and important for everyone - not every wayland compositor is a desktop, wayland runs on smartphones and other devices. desktops should provide desktop-specific parts(jointly if they wish)

[pal666]

Providing the protocol that only handled a subset of features without a real implementation of it that can be integrated into currently DE's is what the biggest mistake was.

your biggest mistake is to discuss stuff in which you have zero understanding

[pal666]

I think that this doesn't reflect the reality. A lot of people use Xorg, because wayland.. doesn't give any advantage to justify the switch

lol. in non-alternative reality most people use browser and have no idea whether it runs on xorg or wayland

I think that an error of the Wayland developers did was to not provide an "equivalent" of X11

i think you are not qualified to judge wayland devs job

This way of working is implemented in the window manager which must have control of the title bar of all windows. Wayland, implemented as CSD, prevent that.

it doesn't prevent it for gnome. are you confusing kde bugs with wayland issues?

[pal666]

You are correct but also misleading. While it is true that Wayland technically speaking is just a protocol like X11, unlike X11 there is a no standard reference implementation that is usable (i.e. Weston doesn't count) so every DE is forced to reimplement the protocols themselves.

moron, you are wrong on two accounts here:
1) xorg isn't reference implementation, it's "one of implementations". it became de facto one after it killed everyone else. for example gnome can become "the wayland" after rest dies.
2) xorg did implement its own window manager, but no de used it. all des were "forced" to reimplemented themselves huge amount of code above x libs. and xorg didn't implement its compositor at all, all des were "forced" to reimplement compoistor themselves.

This means if some software works for X11, it will likely work for every DE.

this is wishful thinking, i.e. bullshit
people, who work on wayland(xorg devs btw), are not as stupid as you and will not repeat every x11 mistake. if people, who write de, want some shared functionality, they are free to implement it in a library and share, they don't need wayland's handholding. your whining will not help them and will not make wayland devs do stupid things

[pal666]

Yes, but in practice you're only expected to use X.org full time, while the others are there just for supporting non-native applications under the given system.

no, your others are part of xorg project. it's like "in practice gnome users are expected to run mutter full time". xorg is one x11 implementation, there are many others unrelated to it. though it's dominant one(just like gnome btw)