Porque é programação de baixo nível não é algo trivial junte isso ao fato de que
Nenhum dos dois é padronizado
Implementar isso é bizarramente caro
Depende de cobaias humanas pra testar (é sério)
Literalmente a coisa 0 a se fazer para implementar é, qual HDR? Qual VRR? É um trabalho disgranhenhento converter um único frame, mesmo Mac OS e Windows não suportam de verdade, simplesmente tem um conjunto de monitores que fizeram parceria com a MS já no caso do Mac a Apple simplesmente faz as telas dela
Eu honestamente não tenho interesse em discutir o porquê, continua significando que a comunidade é lenta. No fim é mais fácil ir para plataforma que funciona.
Mas falando da minha experiência com o Mac OS, todos os monitores que pluguei ajustaram a escala perfeitamente e não precisei configurar absolutamente nada, até mesmo monitores ultrawide que não eram nem FHD nem QHD.
Também todos eles eu apenas precisei, quando necessário, definir o ICC na interface de configuração de telas (alias todos ja vinham com seus próprios perfis de fábrica detectados, até mesmo uma TV aiwa exótica). No Linux isso somente funcionou bem para monitores sRGB, no resto virou um carnaval de conteúdo sRGB sendo exibido errado em quase todo lugar.
O Cosmic do Pop!_OS, o Pantheon do Elementary e o Plasma 6 virão no próximo ano usando Wayland por padrão. Também levando em consideração as outras DEs que estão trabalhando para suportar o Wayland, já dá para cravar que o Wayland é inevitável.
Eu acho que 2024 e 2025 serão os anos do Wayland, porém eu não sei se eu gosto disso. Percebi que o Wayland ainda tem muitas limitações, que muitas vezes são mascaradas pelo XWayland. O impacto do XWayland na performance é uma coisa a se pensar.
Se me derem Wayland para usar, eu uso sem reclamar, mas acho que por enquanto as coisas funcionam melhor no X11.
Eu como usuário comum quase não noto diferença em performance, usabilidade e afins; por mais que ainda sim, o Wayland trava um pouco mais que o X11 no Plasma Shell. Sei que estou no Wayland quando vou usar apps como Spotify, que pelo menos aqui, o app em Flatpak tá crashando na sessão Wayland, além de não conseguir por em tela cheia.
*Pode ser que a versão em Snap não tenha problemas, visto que é a versão oficial oferecida para Linux; mas por mero preconceito ou má vontade minha nunca instalei a versão do Spotify em Snap.
E nem eu porque isso é simplesmente mentira, o kernel Linux tem suporte a centenas de coisas que sequer existem no mercado ainda (mas obviamente são padronizadas) se basear em algo que não é padronizado, não existe sequer meios matemáticos para padronizar e principalmente onde há um suporte baseado em algo feito por quem faz o hardware e o software, é uma falácia lógica que não vale a pena ser discutida
Quando a coisa é padronizada corta metade do caminho, sugiro ver os vídeos do Georges sobre isso, trabalho com um monitor HDR, e o Windows não suporta o range do monitor:v
Ademais: quem criar o framework matemático pra suportar HDR sem ser padronizado além de a comunidade deixar de ser “lenta” com certeza vai ganhar a Medalha Fields (o “Nobel” da matemática) sem qualquer exagero
As únicas DEs realmente compatíveis com Wayland é o Gnome e o Plasma 6 o resto tem suporte parcial ou estão começando em pensar em migrar, além dos entraves que o Wayland tem com os drivers da nvidia, talvez isso se resolva quando de fato as placas do lado verde da força forem integrados ao Mesa driver ou suporte descente via nouveau. Resumindo, está longe um ano do Wayland.
Mas Wayland esta para o futuro assim como systemd.
Como falaram anteriormente, usar o XWayland é como usar o Proton para rodar um jogo nativo do Linux. O XWayland sempre está por ali gastando ciclos da CPU e tal, por mais que não dê para perceber.
A tendência é que jogos rodem melhor com X11, porque com o XWayland você terá os impactos do próprio XWayland e do Proton e terá mais input lag se o compositor não suportar VRR. O Mutter não suporta VRR.
A comunidade quer adicionar HDR tem mais de ano, já existe até um ISO de 2020 na industria se não me engano, atualização da iso ISO 12646:2015 e isso segue se arrastando, logo, pra mim bate com o significado de ser lento, que é querer adicionar algo e ser um dos últimos a adicionar. E aqui eu culpo todo mundo, até a Red Hat, se não me engano ele estão participando do esforço de implementar o padrão.
Talvez o Georges não sabe usar? Não duvido que no Windows a configuração seja mais complicada, no Mac simplesmente funciona e é em apenas um único lugar a configuração. No Linux não tem como dizer que é culpa da pessoa que não sabe usar HDR, afinal o suporte não existe ainda.
Adianta nada ter uma ISO se a indústria ignora a existência dela?
O Georges eu não sei, mas ao contrário de colorspaces simples não existe uma equação unificada para converter, se for para o ISO que você disse o Plasma 6 vai suportar… em placas AMD (porque ainda tem a questão do driver de vídeo), mas quantos monitores implementam essa especificação em particular?
Como eu disse, Mac OS suporta UMA implementação a da própria Apple (que é licenciada inclusive, aí entra quem vai bancar se for seguir o modelo Apple?), aí as fabricantes seguem a implementação que a Apple segue, aí é fácil ser plug and play com uma única classe
E o mais importante, onde estão as cobaias humanas? Porque presumindo que:
Magicamente a indústria resolva adotar o padrão
Alguém apareça com uma solução matemática supereficiente
NVidia e Intel resolvam suportar
Por algum motivo recebam investimento necessário
Os desenvolvedores consigam ser produtivos em linguagens de baixo nível
Cadê a galera de QA? Sem eles ainda que tenha os itens de 1 a 5 (não tem, mas vamos fingir que tem) ainda se arrastaria por anos.
É a velha máxima:
muita gente querendo and pouca gente fazendo == projeto lento mesmo que quem esteja fazendo tenha uma eficiência sobre humana
Não impediu quase todo mundo de implementar algo. Se você não é parte do problema, já ajuda.
Viu como é simples? Já vai de 0% dos monitores suportados para mais que 0%. Pena que, novamente, enquanto discutimos quem é o culpado, ausência de uma equação unificadora, etc, enfim… ~3 anos…
Por exemplo, quem quer faz… Krita foi um dos primeiros softwares a adicionar suporte a pintura HDR, mas só no Windows, foi ao que se propuseram na época. São nuances assim que podem fazer a comunidade ser lenta ou ágil.
Como eu disse, funcionou em todos os lugares, até uma TV Aiwa genérica que não segue padrão algum.
Talvez porque a Apple provavelmente sabe fazer o fallback para uma transformação cartesiana intermediária para o espaço XYZ com gama normalizada, que funciona para qualquer espaço de cor, e que é o que todo mundo que decidiu fazer antes de procurar uma desculpa, usa, como é o caso do Krita.
Bom, se esse é seu pensamento, que nada que eu e os devs (inclusive da NVidia, Intel e afins) disseram influencia e você acha simples (pelo menos é essa a ideia que passa), que tal um PR com a transformação cartesiana que “funciona para qualquer espaço de cor” (apesar de isso ser uma falácia matemática), porque não abre um PR ou pelo menos mostra como isso pode funcionar para HDR?
Para dizerem que não é a implementação mais perfeita e única aceitável? Não… Não que eu ache que o “faz você então” muda os fatos.
O Krita é uma prova open source viva disso, eles nem esperaram o Linux ser capaz e conseguiram fazer isso em uma época em que uma quantia raríssima de hardware suportava. E atualmente, desde o kernel 5.13 suporte via hardware com driver da AMD existe.
Ah, e quanto a “falácia matemática”, da uma olhada no código do Krita… Eles já trabalhavam com HDR em espaços de cor muito antes de isso ser uma coisa disponível nos monitores, alias, com ranges dinâmicos muito maiores do que os de monitores atuais.
Compositores no X11 são mais lentos e usam mais memória porque eles são separados do servidor gráfico (o processo do Xorg) e têm que ficar constantemente se comunicando com ele. Sem compositor, o Xorg tem que desenhar usando a CPU.
No Wayland, a compositor é parte do servidor gráfico – cada DE no Wayland na verdade é seu próprio servidor gráfico. Assim, só tem código pra desenhar usando a GPU.
Isso é uma problema real, o Wayland é um solo fértil para fragmentação. O wlroots preveniu a fragmentação ficar ainda maior dando uma base comum para TWM e ambientes menores, permitindo eles compartilharem correções, mas os dois maiores ambientes (KDE e GNOME) são completamente à parte e o GNOME em especial é que mais se fragmenta do resto (tanto que o mpv tem código para avisar de recursos que faltam no GNOME).
Discussões como HiDPI e HDR em parte não andam por causa de discordâncias entre essas 3 facções.
Infelizmente o wlroots surgiu, o que? Uns 10 anos depois do primeiro release do wayland? Teria sido bom ter uma implementação acompanhando o protocolo. Se bem que teve o Weston.
A propósito do que tenho observado – de a sessão Plasma X11 ainda ser o padrão em todas as distros que tenho experimentado (exceto Fedora) – encontrei ontem essa informação, na Wiki do Debian, atualizada até 31 Agosto 2023:
O suporte do Wayland para SDDM está em andamento, atualmente ele usa o X11 por padrão em todos os lugares. Contudo, SDDM ainda é capaz de iniciar uma sessão do Wayland para um desktop.
(Como sempre, achei vago, ambíguo, meio confuso. Depois de ler isso, fiquei com mais dúvidas do que certezas de ter entendido alguma coisa corretamente).
Também consta lá:
GNOME (supported since 3.20+)
KDE Plasma (supported since 5.4+)
Enlightenment (unsupported)
Support being worked on upstream.
Cinnamon (unsupported)
Support discussed upstream.
MATE (unsupported)
Support planned, source (2014), an update (2019)
É simples de entender, o Display Manager pode usar MIR, Wayland, X11, EGLS… não importa se ele ler os lançadores da pasta certa ele consegue inicializar o Desktop independente qual protocolo gráfico o Desktop usa
Percebi várias mudanças, nos 6 dias entre uma ISO e outra:
Agora, logou automaticamente em sessão Wayland – embora, na seção correspondente, continue dizendo que está configurado para carregar sessão Plasma X11
Pelo que estou vendo, muitos recursos que eu gostava, vão simplesmente desaparecer, com o Plasma 6 – em grande parte, porque são pacotes que estão há tempos sem manutenção, acumulando bugs não-resolvidos, e que talvez só continuassem funcionando (bem ou mal) por inércia, enquanto o resto do KDE não mudava o suficiente para invalidá-los.
Sem mantenedores ativos, não há como usá-los no Plasma 6 – e parece que a equipe do KDE está fazendo uma “limpa geral”.
Resultado: – Inúmeros “antigos recursos” vão desaparecer – e com eles, a sessão X11 vai ficar cada vez mais “capada”.
Com isso, as distros vão acabar tendo de aceitar Wayland como padrão no KDE, mesmo que ainda não pareça “perfeito” – afinal, o que significa “perfeição”? – O Wayland, agora, só vai acelerar, cada vez mais. Os esforços e as atenções vão se concentrar nele, enquanto o X11 vai ficando para trás.
Apesar de o Plasma 6 ter “poucas novidades” (por enquanto), começo a ficar impressionado com 2 coisas:
O “enxugamento” geral de antigos recursos e opções – o que “alivia” o quadro, e abre mais espaço para novidades logo à frente
A reorganização geral do System Settings – onde já não consigo encontrar nada, sem recorrer ao campo de Busca. – Falam em “simplificar”, mas até agora, só complicou minha vida (rs).
