Wayland 1.25

Изложи юзкейсы.

и на иксах при нехватке vram прозрачно используется ram

Это не правда. На венде да есть расширение за счет RAM, а на иксах также не работает. По крайней мере для CUDA я точно это знаю(по работе надо было). Могу ссылок на форум невидии накидать, где это обсуждают и просят сделать в драйверах чтобы как в венде было.

Вот я искал решение проблемы. Это точно было на иксах.

Расширить GPU Total memory

Возможно если по чуть-чуть VRAM забирать оно и работает как-то, но если надо сразу 4Гб на 3Гб 1060 загрузить, падало обязательно. А на венде работало.

https://forums.developer.nvidia.com/t/non-existent-shared-vram-on-nvidia-linu...

Вот тут до сих пор обсуждают проблему

Для CUDA - возможно. Для игр - работает (UE5 это прям отличный тест. Он течёт по vram как не в себя). Оно и на вяленом c egl-wayland2 немножко работает, но не долго (я по mangohud и тормозам вижу, что оно упёрлось в мои 10 гиг vram, после чего может проработать пять минут, может 10 секунд и вылететь. на иксах просто падали фпс)

my theory is still that most Wayland clients cannot handle a situation where a memory allocation would be rejected, and then just crash.

Вот что там пишут. Что очень похоже на правду.

Но опять же. Я не сталкивался с падениями игорей на своих 12Гб. Вот из последнего - Reanimal на UE5. Если судить по mangohud, то потребление VRAM крутилось около 12Гб(4к всё на ультрах), но ничего не падало.

То что ты комментом ниже написал, только без окна контейнера. Тебе дают область, в которой ты по x,y относительно координат области можешь ставить свои окна.

Тем временем сама зона находится под управлением композитора и он по прежнему ей управляет, как мало чем отличающимся top-level окном и оно по прежнему ему не указ, что и как делать.

Т.е. с одной стороны не нарушается изоляция и независимость композитора, с другой расстановку собственных окон таки наныли, хоть и в индивидуальном загончике.

Вообще, почитать сам протокол таки полезно, люди старались, писали кучу поясняющего текста. На gitlab даже с картинками.

Я это всё читал, там немного сложнее.

UE5 корректно обрабатывает VRAM OOM (показывает ошибку).

А вот другой софт, включая композиторы - нет. Более того, композиторы зачастую реквестят device-local память на вяленом (поэтому драйвер не может отдать ram вместо vram) и только зря расходуют vram.

Я, честно говоря, хз, как оно работает на AMD/Intel (говорят, что работает). Возможно там драйвера просто забивают болт на то, что софт хочет device-local (vram) память

Считывать нажатия клавиш, координаты мыши и нажатия её кнопок system-wide, не только в своем приложении. Эмулировать движения мыши и нажатия кнопок в любом приложении, не только в своем приложении.

И не надо меня убеждать, что это мне не нужно

Тебе дают область, в которой ты по x,y относительно координат области можешь ставить свои окна.

Мне нужна область размером с весь экран. А не с теми размерами, которые кто-то там разрешил

Здесь даже картинки есть. Текст ровно над ними об этом.

которые кто-то там разрешил

А указывать композитору тебе никто и не разрешит. Композитор может хоть изъять окно из зоны, хоть изменить масштабирование, хоть её вообще грохнуть. Короче, RTFM по ссылке, там всё написано.

Поискал проблемы с VRAM в багтрекере Hyprland, не нашел ничего похожего по описанию(падение при исчерпании). Может я не сталкивался потому что в этом конкретном композиторе этой проблемы нет?

Мне нужна область размером с весь экран. А не с теми размерами, которые кто-то там разрешил

А если пользователь запретил и не хочет чтобы приложение вылезало за свое окно, как быть? Надо же как-то разделять пользователя и разработчика софта.

А если пользователь запретил и не хочет чтобы приложение вылезало за свое окно, как быть?

Я сам разработчик и сам пользователь своего софта.

Я знаю, что оно делает. Я спрашиваю, какой у этого юзкейс.

по видимому, ты мой юмор просто не понял ))) в отличие от других лоровцев

Какой юзкейс у отсутствия эмулироемой клавиатуры, заставить пользователя физически находиться между монитором и табуреткой?

Реальность: разработчики кикада все-таки находят в себе силы патчить кикад для совместимости с вяленым. Рано или поздно это будет допилено.

Но не по твоему

Не важна. Дизайн можно переделать.

Разрабы кикада в первую очередь смотрят на своих пользовтелей. Поэтому в угожу убожескому сесурити от вяленд-смузятников не собираются понижать своих пользователей в правах и загонять их в рамки убогого гномохида и дропать фичи. И опять же кидаться как голодная собака на косточку экспериментального протокола который реализован в гитхаб-проекте скомпилированном и утсановленном десятком гиков - тоже. Они доходят до той точки где дальше нормально пройти не получается и останавливаются. Когда нужный протокол будет реализован - и не в эскпериментальном патче кивина а стандартно в энтерпрайз дистрах - тогда пойдут дальше. А пока у них стоит пуленепробиваемая затычка хардкодом вызывающая Xwayland - так то практически никто кроме самих разрабов кикада или прусы обычно не догадывается что оно не работает под вейландом.

А то что рано или поздно допилят - ну допилят. Потому как кикаду а и автодеску по большому посрать на интырпрайз линукс - это смешные проценты их юзеров. Те кому сильно надо - поставять икс. А вот интерпрайз дистрам вполне себе не мешает обеспечить своим дистрам совместимость с интерпрайз продуктивным софтом - так что это движение пойдет в две стороны. И придет таки к полной совместимости но не вот так как ты ту верещишь со своими отсылками с 4.2 - а, экпериментальный протокол родили - все готово. Нихрена не готово. Готово будет когда можно будет прорелизить бинарынй кикад под вейланд и сказать что он совместим с такой-то версией шапки и с такой то версией убунты и с гномом и с кедами (хотя-бы, не будем уж настаивать на минорщине) без приписки «а чтобы оно было совместимо скачайте и соберите вот эти пять экспериментальных софтин с гитхаба». И вот на это и потребуется еще лет несколько от момента принятния экспериментального протокола до поддержки его основным композиторами тех самых этнрпрайз дистров.

Хорошо, объясню.

Есть некая программа (чужая), с окном распахнутым на весь экран. В окне несколько областей с данными. И есть моя программа, окно 200х400, поверх всех окон.

По нажатию определенных клавиш клавиатуры [независимо от того, где находится фокус клавиатурного ввода] мне нужно считать данные из окна чужой программы, передать в свою программу, обработать эти данные и, в зависимости от результатов обработки, програмно двинуть мышь и нажать те или иные кнопки в чужом окне. т.е. чтобы не я сидел и тыкал в кнопки, а моя программа делала это за меня без моего участия.

И чтобы окно моей программы можно было передвинуть в любой участок экрана, чтобы не перекрывать нужную часть окна с данными. В любую локацию, а не только туда, где выделена эта пресловутая «зона»

Позволяет это вяленый?

X сервер и не должен ничего масштабировать. Это тулкит должен на разных мониторах рисовать по разному, если мониторы имеют разный dpi (именно так делает gtk когда работает с wayland композитором). И dpi монитора X сервер знать не обязан, он может просто хранить в X ресурсах с именами OUTPUT.dpi то, что ввёл пользователь в диалоге Настройки мониторов. Просто такого соглашения между тулкитами не срослось, есть только соглашение про глобальный Xft.dpi. И не срастется, потому что «X11 это легаси».

Это тулкит должен на разных мониторах рисовать по разному

Да.

если мониторы имеют разный dpi

Нет, DPI != масштабирование.

Возьмем например, систему верстки, которая выводится на монитор. Ее контролы должны быть в одном масштабе (регулируемом по желанию юзера в зависимости от разрешения), а отображаемая страница всегда должна соответствовать DPI.

Я понимаю, что ты хочешь сделать, но всё еще не вижу здесь юзкейс. Давай, попробую угадать: ты хочешь повесить автоматизацию действий с чужой программой во время взаимодействия с ней же? То есть, ты с ней работаешь, твой скрипт сбоку ловит нажатия, отправленные этой программе и досылает что-то еще, я правильно понял?

эмулироемой клавиатуры

ydotool, wlrctl

заставить пользователя физически находиться между монитором и табуреткой?

Если тебя хотят физически заставить находиться перед компом, то комп будет не твой, и на нем будет стоять всякий интересный софт для этого. И иксовые приблуды тебе не помогут, потому что всё это будет детектироваться.

в угожу убожескому сесурити от вяленд-смузятников

Ты в принципе не читаешь, что тебе пишут, не так ли? Просто я не вижу иных причин, почему ты продолжаешь распространять свои бредни - разве что вера в них тебе дороже истины. Мы же с тобой уже выяснили, что это не связано с безопасностью: Wayland 1.25 (комментарий)

кидаться как голодная собака на косточку экспериментального протокола

Чтобы не кидаться на косточку - достаточно передизайнить интерфейс таким образом, чтобы он не трабовал многооконности. Почти весь современный софт, включая профессиональный, этого не требует.

Те кому сильно надо - поставять икс.

Зачем, если ты сам говоришь, что есть xwayland? У тебя в голове какая-то каша.

А вот интерпрайз дистрам вполне себе не мешает обеспечить своим дистрам совместимость с интерпрайз продуктивным софтом

Ага, через xwayland.

со своими отсылками с 4.2

4.2 - это твои бредни про безопасность и прочее отрицание реальности, чем ты обычно тут и занимаешься.

Нихрена не готово.

Этого и не заявлалось, заявлялся факт смерживания протокола и наличие экспериментальной реализации, с выражением надежды, что поддержку допилят.

И вот на это и потребуется еще лет несколько от момента принятния экспериментального протокола до поддержки его основным композиторами тех самых этнрпрайз дистров.

Всё так, только совершенно непонятно, зачем ты выдаешь это за свою собственную уникальную мысль.

Вообще суть была именно про отказ от самого X-сервера как чего-то, чему тоже надо отправлять данные, что обычно и приводит к тирингу и оверхеду, а также к потенциальным проблемам с безопасностью, когда приложения могут через X-сервер (поэтому и «божественная» сущность) влазить в другие программы. Типа всё в одном в одном флаконе, но шустро и безопасно, а с этими экспериментами опционально и модульно, если у них получится разделить оконник и композитор, при этом не добавляя очередной «X-сервер».

В Линуксе я вообще относительно недавно (именно на постоянной основе), поэтому прошу поправить, если что не так…

Поправляю. Изначально вэйланд продавали под соусом «иксы большие и сложные и содержат кучу модулей, а это всё не нужно, чтобы локально картинки на поверхностях рисовать». В итоге пришли к горе протоколов разной степени проработанности, реализованных в разной степени в разных композиторах. Сложность только увеличилась, фрагментация экосистемы существенно возросла, а скорость … ну, получили несколько процентов прироста производительности на синтетических тестах. Такой вот результат почти восемнадцати лет попыток переписывания графического стека на линуксе.

По-моему dpi и масштабирование это одно и то же. Это просто вопрос отображения в интерфейсе Настроек монитора. Либо пользователь выбирает 100%, 125%, 150%, 200%, либо выбирает 96 dpi, 120 dpi, 144 dpi, 192 dpi.

Мой поинт был в том, что в протоколе X11 не требуется чего-то нового для поддержки mixed dpi (mixed scaling). Проблема не в протоколе X11 и не в сервере Xorg, проблема в тулкитах.

По-моему dpi и масштабирование это одно и то же.

Ну я же объяснил, почему нет. DPI - это соотношение виртуального пиксельного пространства к реальности, буквально количество точек в дюйме. Лист A4, рендерищийся на мониторе, должен быть того же размера, что и приложенный к монитору физический лист бумаги. При это для остального интерфейса может быть выставлен масштаб 150%, потому что монитор 4K и при нативном разрешении юзер будет плохо видеть контролы.

Я понимаю, что ты хочешь сказать, что есть другие способы решения моей задачи, без xdotool и xinput.

Конкретный функционал программы я тебе не скажу. Просто скажу, что других способов взаимодействия с окном чужой программы, кроме как визуально снимать информацию с экрана нет. Нет никаких api, никаких dbus и других подобных каналов. Чужая программа не коммуницирует ни с кем. Поэтому в иксах только xdotool и xinput. А в винде через winapi.

повесить автоматизацию действий с чужой программой

Кто между свободой и безопасностью выбирает безопасность, тот остается и без свободы, и без безопасности. (с) кто-то из древних.

Удивительно, как плохо вейланд состарился за свои 15 лет. XML теперь опале. Банкинг ушел в мобильный банкинг. Ковид убил тонкие клиенты в пользу WFH. Браузеры утомились виджет-сетами и повыбрасывали. WINE-шеллы появились мягкие и шелковистые. Десятки тысяч стримеров-инфлюенсеров хотят просто чтобы все работало.

В любом случае, иксы всё мылят by design, и это никто за 40 лет не исправил.

Эта… на аналоговом «мыло» не так чтоб имеет физический смысл какой-то.

Я понимаю, что ты хочешь сказать, что есть другие способы решения моей задачи

Да не хочу я ничего подобного сказать. Я действительно искренне хочу разобратсья, что именно ты делаешь и, может быть, предложить тебе способ решения твоей проблемы в вяленде. Просто подтверди или опровергни предложение из предыдущего поста. Я попробую или что-то придумать, или скажу, что хз, что делать %)

безопасность

Еще один с заблуждениями про безопасность. Читай: Wayland 1.25 (комментарий)

Эта… на аналоговом «мыло» не так чтоб имеет физический смысл какой-то.

DVI (цифровой интерфейс) появился в 1999 году. Уже спустя несколько лет он стал достаточно распространенным.

Профессиональные рабочие станции на юниксе, например, старшие модели Sun Ultra, существовашие до середины нулевых, использовали DVI (и, кажется, даже комплектовались видяшкой с двумя DVI из коробки).

Нетрудно сделать вывод, что вопрос о поддержки масштабирования стоял в полный рост как минимум с начала нулевых, то есть, примерно 25 лет. И за это время никто так и не почесался решить эту проблему по многократно обозначенной мною причине: это капитально ломает весь протокол.

Читай: Wayland 1.25 (комментарий)

Этот комментарий нерелевантен. Это как смотреть на дерево и не видеть леса. В частности, твой тейк про условный SendKeys и про спец-тулзы. Мне очевидно, что авторы вейланда когда думали про безопасность, то вдохновлялись банковским веб-приложением, где пин надо было вводить мышкой по случайно расположенным кнопкам 0-9. И еще кто-то один был травмирован спрятанной кнопкой «подписаться» под кликбейтной картинкой-превью.

А вот в сферические координаты не верится совершенно. Если бы кто-то там задумался о сферических координатах, то и о дробном масштабировании задумался бы.

Собака на сене. Празднуем большую победу, что удалось один конкретный костыль под нее протащить.

Этот комментарий нерелевантен.

А вот в сферические координаты не верится совершенно.

Ясно, отрицание реальности в угоду собственным верованиям.

Можешь попробовать разработать соответствующее расширение для иксов. Потом вернешься и расскажешь нам, как оно было.

Можешь попробовать разработать соответствующее расширение для иксов. Потом вернешься и расскажешь нам, как оно было.

Там наоборот. У меня голый VT1. На этом VT1 включаю ускоритель графики и запускаю свой «скринсейвер» с сайта шейдер-тойс. И одной из текстур отдельно рисую браузер, который работает с Xfb (но думает, что работает с X11).

ну все таки зона не совсем окно а скорее экран монитора. и то что это только сейчас добавили - прямое следствие что (как говорили сами авторы вяленого) wayland is gay и из-за этого в Qt и Gtk наделали своих собственных причем несовместимых между собой расширений. то есть по факту у нас есть аж три разные реализации управления окнами причем та что «стандарт» не поддерживается тулкитами.

с тулкитами проблема в другом: там рисование часто уже давно сделано «по пикселам». масштабировать то надо не только букавки, но и например обрамление кнопок, менюшек, иконки…

а в том же Qt все координаты в QPainter подаются в пикселях.

And Xorg is trans.