The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..., opennews (??), 23-Май-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


14. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +7 +/–
Сообщение от rob pike (?), 23-Май-15, 12:44 
Без D-BUS-то ну совершенно же никак этого невозможно было сделать.
Ответить | Правка | Наверх | Cообщить модератору

15. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 23-Май-15, 13:02 
Учитывая, что у них всё через D-Bus построено - добавлять какой-то другой механизм было бы крайне глупо.
Ответить | Правка | Наверх | Cообщить модератору

16. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +4 +/–
Сообщение от rob pike (?), 23-Май-15, 13:11 
Вместо того чтоб вылезать из тоннеля, продвинемся еще немного вглубь.
Логично.
Ответить | Правка | Наверх | Cообщить модератору

18. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 23-Май-15, 13:35 
С точки зрения существующе кодовой базы вполнелогично. Если затевать революцию - то не с этого а, например, с описания новой арзитектуры, базирующейся на чём-то другом.

Я, честно говоря, не понимаю, в чём в данном случае проблема - именно для подобных задач D-Bus подходит отлично. Дискавери, подписки - всё, что нужно.

Ответить | Правка | Наверх | Cообщить модератору

20. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 23-Май-15, 14:05 
ИМХО лучше для подобных задач подходит sysfs - унифицирован для всех устройств, а не только для датчиков, ненужны библиотеки и уж тем более демоны и завязки за конкретные системы инициализации.
Ответить | Правка | Наверх | Cообщить модератору

22. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +2 +/–
Сообщение от Аноним (-), 23-Май-15, 14:26 
> лучше для подобных задач подходит sysfs

как событие поставить на изменение значения? через неработающий с sysfs inotify или через опрос каждые 20-100мс, который будет разряжать батарейку?
Если программок будет 20 штук на датчик, каждая будет постоянно ломиться в этот sysfs файл?

Ответить | Правка | Наверх | Cообщить модератору

24. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 23-Май-15, 14:53 
>> лучше для подобных задач подходит sysfs
> как событие поставить на изменение значения? через неработающий с sysfs inotify или
> через опрос каждые 20-100мс, который будет разряжать батарейку?
> Если программок будет 20 штук на датчик, каждая будет постоянно ломиться в
> этот sysfs файл?

А как conky работает? Как предлагаемый iio-sensor датчики опрашивает?

ИМХО если датчик сугубо информативный - опрашивать его чаще чем 1 раз в секунду нет смысла. Если датчик управляющий - то его в любом случаее придется опрашивать с определенной частотой иначе он просто зафлудит евентами.

Не вникал как у sysfs отслеживаются события от драйвера, но что-то там было. В любом случае лучше доработать sysfs, чем плодить новые прослойки завязанные не пойми за что.

Ответить | Правка | Наверх | Cообщить модератору

39. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от Аноним (-), 23-Май-15, 17:21 
> А как conky работает?

Возьми strace да посмотри. Он вполне может и поллить запросто. Когда его писали - на эффективность от работы от батарейки, как бы это вам сказать...

> Как предлагаемый iio-sensor датчики опрашивает?

Вполне вероятно что поллингом.

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

В N900 вон через d-bus рулятся почти все аспекты управления телефоном. Можно скажем system-wide запросить "самолетный режим". Даже из скрипта. Или программы. Удобно, что бы там мамонты не вякали.

А на обычном писюке сказать "а ну все радио заткнулись" как-то так по простому в общем то и нельзя в результате. Во зашибись, зато без d-bus.

Ответить | Правка | Наверх | Cообщить модератору

43. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 23-Май-15, 18:40 
>> А как conky работает?
> Возьми strace да посмотри. Он вполне может и поллить запросто. Когда его
> писали - на эффективность от работы от батарейки, как бы это
> вам сказать...

Скорее наоборот - conky опрашивает датчики с заданным интервалом (устанавливается пользователем). Большинство датчиков не активны, пока не будет к ним обращения. Поэтому для них и не работает inotify.

Получается, что conky будет опрашивать все необходимые датчики раз в секунду. А iio-sensоrs будет опрашивать датчики и генерировать события гораздо чаще -  10-100 раз в секунду, ведь он не знает как часто они нужны приложению. Опять же, скорее всего iio-sensоrs будет отсылать одним сообщением все параметры датчика, даже если они не нужны для конкретного приложения.

Я давал ссылку на лор - там все эти аспекты обсудили.

> Можно скажем system-wide запросить "самолетный режим". Даже из скрипта. Или программы.

Какие гарантии, что все приложения обработают это сообщение корректно и действительно перестанут использовать радио связь? Должно быть не только удобно, но и надежно. ИМХО единственный надежный вариант - запрет связи на уровне драйвера, да и то если это не usb-wifi (со своей ОС) который может сам начать проверять обновления.

Ответить | Правка | Наверх | Cообщить модератору

58. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 23-Май-15, 21:48 
Никто не мешает - в качестве одной из ракций - какому-то компоненту погасить связь через драйвер, если оно действительно нужно. Но при этом все приложения будут знать, что мы ушли в режим полёта и на связь можно не рассчитывать. И вести себя соответственно.
Ответить | Правка | Наверх | Cообщить модератору

63. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 23-Май-15, 22:23 
> Никто не мешает - в качестве одной из ракций - какому-то компоненту
> погасить связь через драйвер, если оно действительно нужно.

Какому именно? Если устройств связи несколько, как он определит какие гасить?

> Но при этом
> все приложения будут знать, что мы ушли в режим полёта и
> на связь можно не рассчитывать. И вести себя соответственно.

Сейчас, как ни странно, при отключении сетевого кабеля все приложения использующие сеть тоже узнают, что ее нет (при попытке к ней обратиться).


Ответить | Правка | Наверх | Cообщить модератору

67. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 23-Май-15, 23:27 
Ну вот то что решало - какое устройство поднимать, то и опусти. Или ещё как - вопрос полиси, которая шине ортогональна.

А принцип "ткнёмся - тогда и узнаем" - это и есть проблема, о которой я говорю. Влезли в своп - узнаем по тормозам. Отпала сеть - узнаем по ошибкам. Диск умирает - давайте его добьём торрентами. Место заканчивается на устройстве - нет, мы дисковый кэш свой ограничивать не будем - пусть всё дотупит до 0 байт, тогда узнаем. И так далее. Мне кажется, вменяемое взаимодействие софта между собой - гораздо лучшая идея.

Ответить | Правка | Наверх | Cообщить модератору

75. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 24-Май-15, 00:46 
> Ну вот то что решало - какое устройство поднимать, то и опусти.

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

> А принцип "ткнёмся - тогда и узнаем" - это и есть проблема, о которой я говорю.

Это не проблема. Это проверка на ошибки.

> Влезли в своп - узнаем по тормозам.

Сейчас приложение не может узнать сколько памяти реально осталось?

> Отпала сеть - узнаем по ошибкам.

Вы предлагаете не проверять ошибки сети (обрыв провода, зависание сервера, etc)?
Если нет, то что даст дополнительное уведомление?

> Диск умирает - давайте его добьём торрентами.

Зачем посылать в такой ситуации сообщения приложениям? Достаточно уведомить админа/пользователя и перевести проблемные диски в ro или вообще их отключить.

> Место заканчивается на устройстве - нет, мы дисковый кэш
> свой ограничивать не будем - пусть всё дотупит до 0 байт,
> тогда узнаем.

Для этого существуют дисковые квоты.

> И так далее. Мне кажется, вменяемое взаимодействие софта между
> собой - гораздо лучшая идея.

Возможно. Но вопрос в том, где и что и как реально должно взаимодействовать. Есть pipe, fifo, сигналы (kill -s). Да d-bus имеет больше возможностей, но в ущерб скорости, да и в реальной практике редко когда эти возможности нужны, а там где реально востребованы (audio) есть более специализированные решения с учетом всей специфики (jack).

Ответить | Правка | Наверх | Cообщить модератору

113. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 25-Май-15, 13:54 
Проверка на ошибки, да. А дать механизм, который бы ошибку предупредил - религия не позволяет?

Я предлагаю оставить проверку ошибок в покое, а при возможности - уведомлять приложения о различных событиях/изменениях состояния как можно раньше. Чтобы (по крайней мере в штатном случае) не молча обрывалось соединение в самый неподходящий момент, когда приложение будет ждать ответ на DNS-запрос пол-минуты (и, соответственно, крутить индикатор ожидания пользователю). В ряде случаев это не поможет - но в большинстве ситуаций - улучшит user experience.

Нет, если на диске вырос relocation, или ещэ как SMART ругнулся - это не повод паниковать и уходить в readonly и нарушать какие-то важные активности пользорвателя. Но это вполне себе повод: 1) уведомить пользователя, что диск не особо надёжен 2) до его решения ограничить незначимый но интенсивный I/O. И уж точно принятие решения, что надо ограничивать и какие меры принимать - дело отнюдь не ядра, а либо самого приложения, этот I/O осуществляющего, либо работчего окружения, держащего общую конфигурацию.

С дисковыми квотами результат тот же - какой смысл загонять приложение в нештутную (даже если  и обрабатываемую) ситуацию? Сидит, значит, пользователь, обрабатывает здоровенный графиечский файл - и вдруг выясняет, что сохранить он его не может - не важно, места нет или приложение/пользователя квотами обрезали. А А обработать прозрачно - религия не велит? Чтобы, допустим, рядом сидящий браузер кэш от недавно просмотренных видео почистил?

И, соответственно, речь не об audio, а обо всём спектре событий - от информации от железа до соообщений, отосланных из пользовательского скрипта.

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

118. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 26-Май-15, 01:28 
> Проверка на ошибки, да. А дать механизм, который бы ошибку предупредил -
> религия не позволяет?

Пока не вижу ситуаций, где это действительно былобы оправдано.

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

Потеря пакетов или сигнала (3g/wifi) вполне обычная ситуация и должна быть обработана корректно.

> когда приложение будет ждать ответ на DNS-запрос пол-минуты (и, соответственно,
> крутить индикатор ожидания пользователю). В ряде случаев это не поможет -
> но в большинстве ситуаций - улучшит user experience.

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

> Нет, если на диске вырос relocation, или ещэ как SMART ругнулся -
> это не повод паниковать и уходить в readonly и нарушать какие-то
> важные активности пользорвателя. Но это вполне себе повод: 1) уведомить пользователя,
> что диск не особо надёжен

Конкретную реакцию должен определять администратор.

> 2) до его решения ограничить незначимый
> но интенсивный I/O. И уж точно принятие решения, что надо ограничивать
> и какие меры принимать - дело отнюдь не ядра, а либо
> самого приложения, этот I/O осуществляющего, либо работчего окружения, держащего общую
> конфигурацию.

Такой подход не приемлем. Мы получим либо тормоза, либо продолжение активного i/o. Приложения сами по себе ничего не должны решать. Должна быть задана конкретная реакция на конкретную проблему. Оставлять такие вещи на усмотрение программ и наедятся что авторы были не дураки и все продумали как минимум наивно. Всегда найдется та программа, которая проигнорирует подобное сообщение.

> С дисковыми квотами результат тот же - какой смысл загонять приложение в
> нештутную (даже если  и обрабатываемую) ситуацию? Сидит, значит, пользователь, обрабатывает
> здоровенный графиечский файл - и вдруг выясняет, что сохранить он его
> не может - не важно, места нет или приложение/пользователя квотами обрезали.

По-вашему сейчас приложение не может проверить/зарезервировать свободное место, до начал операции? Насколько я помню тот же transmission заранее предупреждает, если на разделе заканчивается место.

> А А обработать прозрачно - религия не велит? Чтобы, допустим, рядом
> сидящий браузер кэш от недавно просмотренных видео почистил?

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

ИМХО вполне нормальная практика просто оповестить пользователя, о том что место заканчивается. А уж что лучше удалить он решит сам. А то получится, что пользователь смотрел online фильм и копировал тучу фильмов на съемный диск. Но лажанулся и отправил не на тот диск. Сперва у него начал дергаться фильм, так как удалился из кэша, а затем все равно кончилось место.

> И, соответственно, речь не об audio, а обо всём спектре событий -
> от информации от железа до соообщений, отосланных из пользовательского скрипта.

Я не отрицаю, что где-то это может быть полезно. Но призываю лишний раз подумать, а надо ли оно в конкретной ситуации.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

72. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 24-Май-15, 00:09 
> Скорее наоборот - conky опрашивает датчики с заданным интервалом

ВНЕЗАПНО, именно это и называется polling :D

> Большинство датчиков не активны, пока не будет к ним обращения.

Вот это совсем не факт. За все датчики расписываться как-то сильно шустро, не?

> Поэтому для них и не работает inotify.

А с практической точки зрения - надо постоянно клевать датчик из программы, пробуждая программу и тыкаясь в датчик.

Самое очевидное: free fall detector например явно работает всегда. А вот его состояние поллингом проверять - нерезультативно. Если вы будете его раз в секунду проверять, ноут за эту секунду успеет приложиться уже. С работаюшим хардом. Царапнув поверхность диска. А если его дергать часто - программа не даст процу в low power режим уйти скорее всего.

И да, а коньки как-то обрабатывают переход системы на батарею? Ну там скажем от адаптера - можно большинство датчиков 10 раз в секунду сканить, а от батареи - лучше раз в пару секунд. В то что гном с профайлами питания и d-bus так сможет - я еще поверю.

> 10-100 раз в секунду, ведь он не знает как часто они нужны приложению.

О, это идея! Внедрить kdbus в ядро и пусть ядро сразу и рассылает по kdbus, сразу по факту доступности инфы от железки :).

> Опять же, скорее всего iio-sensоrs будет отсылать одним сообщением
> все параметры датчика, даже если они не нужны для конкретного приложения.

Проблема скорее в том что проц не уходит на пониженные частоты/в глубокие режимы сна если кто-то дергается. И когда это хренадцать программ, читающих датчики всех мастей - получаеся "не очень".

Грубо говоря, если 5 программ надо температуру проца, в обычном случае все 5 будут дергать датчик. А так один демон дернет датчие и раскидает всем 5 заинтересованным, по мере необходимости, что по идее эффективнее.

> Я давал ссылку на лор - там все эти аспекты обсудили.

Я не посещаю LOR, увы. Посылать меня туда бесполезно.

> Какие гарантии, что все приложения обработают это сообщение корректно

Так же как и со всеми остальными программами. За системные - отвечают QA которые тестировали релиз. Апликухи которые поставил юзерь ... для них это в общем случае скорее информативный сигнал. Ну то-есть они могут скажем корректно свернуть сетевую активность, если хотят, зная что сейчас сеть пропадет. А не хотят - активность зарубится как получится. Когда системный компонент пойдет и потушит сетевой интерфейс.

Зато все это рулится одной кнопой из гуя - offline mode. Или скриптом - одно сообщение по dbus. Удобно. Одно логически сгруппированное действо - одним действием с системой, с минимальным шансом сделать что-то не так. И минимально необходимыми знаниями - "хочу самолетный режим". Программе или скрипту "кнопочка самолетного режима" нафиг не упало знать скажем полный список сетевых и-фейсов и как их правильно потушить. D-bus это обеспечивает.

> и действительно перестанут использовать радио связь?

Это будет чуть иначе: системные компоненты потенциально заинтересованные в сообщении подпишутся на него заранее. А получив его - пойдут да вырубят радио на "своих" железках. Отправителю сообщения вообще не надо знать кто и как это будет делать, ему надо только запросить самолетный режим. Остальное не его сложности. Элементарное разделение труда.

Обычные программы ... могут принять к сведению сообщение и что-то сделать, понимая что системные компоненты сейчас уберут сеть. А могут ничего не делать - тогда их просто обуют на сеть неожиданно для них. "Продолжить использовать" интерфейс который системные компоненты форсанули down - у программ не получится по причинческим технинам :P.

Ну то-есть зайдя как рут - можно это переиграть, ессно. Чудес не бывает: рут может всё. Но обычные юзермодовые программы в общем случае просто обломаются. Или ожидаемо для себя, если они подписались на сообщение, или ВНЕЗАПНО, если не подписались.

> Должно быть не только удобно, но и надежно.

В общем случае обычные юзермодовые программы ничего не могут сделать по поводу того что системные компоненты с повышенными привилегиями пришли и выключили по сообщению интерфейсы. Рут конечно и в африке рут, но защищаться от рута никто и не собирался.

И да, вы можете предложить решение лучше? Чтобы было столь же просто для инициатора?

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

> ИМХО единственный надежный вариант - запрет связи на уровне драйвера,

Ну то-есть вы хотите сказать нам что kdbus очень нужен и полезен? :)

> и то если это не usb-wifi (со своей ОС) который может
> сам начать проверять обновления.

Большинство usb-свистков таки относительно простые штуки. А то что вы имеете в виду - это извините мобильные роутеры и прочие, а не свистки. Самостоятельные (!!!!) компьютеры. Это такой намек что d-bus надо еще сетевое межсистемное конективити по хорошему, чтобы и такие штуки были в курсе что им надо заткнуться? :) А еще в идеале неплохо бы после предупреждения снять питание с девайса. На всякий. И питание экономится, и что-то там обновлять девайс в общем случае не сможет :)

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

76. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 24-Май-15, 01:31 
>> Большинство датчиков не активны, пока не будет к ним обращения.
> Вот это совсем не факт. За все датчики расписываться как-то сильно шустро,
> не?

Еще раз  "Поэтому для них и не работает inotify.", для тех что обновляются сами можно получить событие через inotify.

>> Поэтому для них и не работает inotify.
> А с практической точки зрения - надо постоянно клевать датчик из программы,
> пробуждая программу и тыкаясь в датчик.
> Самое очевидное: free fall detector например явно работает всегда.

Значит и inotify для него работает.

> И да, а коньки как-то обрабатывают переход системы на батарею? Ну там
> скажем от адаптера - можно большинство датчиков 10 раз в секунду
> сканить, а от батареи - лучше раз в пару секунд.

Все зависит от вашей фантазии - вплоть до перехода на другой конфиг с отключением лишних показаний.

> Проблема скорее в том что проц не уходит на пониженные частоты/в глубокие
> режимы сна если кто-то дергается. И когда это хренадцать программ, читающих
> датчики всех мастей - получаеся "не очень".
> Грубо говоря, если 5 программ надо температуру проца, в обычном случае все
> 5 будут дергать датчик. А так один демон дернет датчие и
> раскидает всем 5 заинтересованным, по мере необходимости, что по идее эффективнее.

А если запущен только один conky и читает он датчики очень выборочно и не все параметры?

Сколько при этом раз демон дернет датчик за секунду? Пять программ могут дергать раз в секунду и только нужные параметры конкретных датчиков. Демону же придется рассчитывать на худшее и дергать 10-100 раз в секунду и все параметры.

>[оверквотинг удален]
> Так же как и со всеми остальными программами. За системные - отвечают
> QA которые тестировали релиз. Апликухи которые поставил юзерь ... для них
> это в общем случае скорее информативный сигнал. Ну то-есть они могут
> скажем корректно свернуть сетевую активность, если хотят, зная что сейчас сеть
> пропадет. А не хотят - активность зарубится как получится. Когда системный
> компонент пойдет и потушит сетевой интерфейс.
> Зато все это рулится одной кнопой из гуя - offline mode. Или
> скриптом - одно сообщение по dbus. Удобно. Одно логически сгруппированное действо
> - одним действием с системой, с минимальным шансом сделать что-то не
> так. И минимально необходимыми знаниями - "хочу самолетный режим".

Ну а сеть чем вы настраиваете? Логичнее поместить этот режим как один из профилей настройки сети.


> Программе или
> скрипту "кнопочка самолетного режима" нафиг не упало знать скажем полный список
> сетевых и-фейсов и как их правильно потушить. D-bus это обеспечивает.
>> и действительно перестанут использовать радио связь?
> Это будет чуть иначе: системные компоненты потенциально заинтересованные в сообщении подпишутся
> на него заранее. А получив его - пойдут да вырубят радио
> на "своих" железках. Отправителю сообщения вообще не надо знать кто и
> как это будет делать, ему надо только запросить самолетный режим. Остальное
> не его сложности. Элементарное разделение труда.

Вот именно - это должно быть в сетевом конфигураторе. А не в каждом сетевом приложении.

> И да, вы можете предложить решение лучше? Чтобы было столь же просто
> для инициатора?

Инициатор - пользователь? Кнопку в конфигураторе или опцию если конфигуратор консольный. И можно обойтись без сообщений, их обработки и демонов.

>> ИМХО единственный надежный вариант - запрет связи на уровне драйвера,
> Ну то-есть вы хотите сказать нам что kdbus очень нужен и полезен?
> :)

У программы под рутом и так хватит привилегий для этого.

>> и то если это не usb-wifi (со своей ОС) который может
>> сам начать проверять обновления.
> Большинство usb-свистков таки относительно простые штуки. А то что вы имеете в
> виду - это извините мобильные роутеры и прочие, а не свистки.

ХЗ все виданные мной huawei за последние лет пять именно такие. Даже если прикидываются обычным ppp.

> Самостоятельные (!!!!) компьютеры. Это такой намек что d-bus надо еще сетевое
> межсистемное конективити по хорошему, чтобы и такие штуки были в курсе
> что им надо заткнуться? :)

Не поможет :) Всегда найдется тот, кто прикинется что ничего не знает и знать не желает.

> А еще в идеале неплохо бы
> после предупреждения снять питание с девайса. На всякий. И питание экономится,
> и что-то там обновлять девайс в общем случае не сможет :)

Вот это верно, давно нужно унифицировать возможность отключать отдельные usb порты.

Ответить | Правка | Наверх | Cообщить модератору

83. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 24-Май-15, 06:39 
> Еще раз  "Поэтому для них и не работает inotify.", для тех
> что обновляются сами можно получить событие через inotify.

А откуда такие сведения взяты? И для начала: а что вами подразумевается под "активностью датчика"?

Я вижу тут как минимум 2 разные сущности:
- Датчик где-то там внутри себя что-то делает (e.g. производит замеры).
- Датчик принимает участие в той или иной активности на шине (e.g. отгружает эти замеры хосту).

Это 2 разные вещи и как они связаны в конкретном случае - весьма зависит от.

> Значит и inotify для него работает.

Хз, я бы это за данность не считал без проверки.

Если что - я достаточно активно интересовался как это работает и имею заметить что сделать энумерацию доступных показометров энного типа через sysfs - то еще приключение. Обход большой иерархии с кучей симлинков, половина которых имеют свойство указывать друг на друга - те еще грабли. А еще и на inotify там потом подписываться... выглядит как куча головняка на ровном месте. На мой взгляд, такой интерфейс к показометрам - не предел мечтаний для апликушников, мягко говоря.

> Все зависит от вашей фантазии - вплоть до перехода на другой конфиг
> с отключением лишних показаний.

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

А чего такого в том чтобы sysfs остался low-level уровнем, а эта штука через dbus - более high-level, где можно как-то по простому запросить у системы нечто типа "а какие градусники есть и что показывают?"

> А если запущен только один conky и читает он датчики очень выборочно
> и не все параметры?

Ну я бы на месте упомянутой штуки тоже читал только датчики, на инфо от которых кто-то подписался.

> же придется рассчитывать на худшее и дергать 10-100 раз в секунду
> и все параметры.

По хорошему - программы могли бы при подписке указывать свой аппетит aka требования к тому как они это хотели бы. А в ответ можно было бы еще и по хорошему сообщить что по факту светит с учетом умений железа и софта. Ну и с учетом аппетитов потребителей показаний дергать. А сейчас в sysfs btw вообще IIRC для датчиков нет никаких данных о скорости с которой датчики могут поставлять инфо, о разрешении и прочем. Подобные данные сейчас можно вообще получить только или экспериментально или после чтения на даташита и/или кода драйвера. Догадайся сам, дорогой апликушник, что этот датчик может. Удобно :)

> Ну а сеть чем вы настраиваете? Логичнее поместить этот режим как один
> из профилей настройки сети.

Как вариант - почему бы и нет? Ну и выставлять сие по свистку от D-bus со стороны того кто эти профили применяет. Да, вы знаете, программа которая просит самолетный режим - совершенно не обязана быть моим менеджером сети! Виджет с кнопочкой или там какой-то обработчик нажатия аппаратной кнопки - совсем не обязан быть менеджером сети или что-то там знать о том какие у меня профайлы, настройки и-фейсов, список этих и-фейсов и прочая.

Есть желание: "не излучать в эфир". Когда юзер нажал вот эту кнопку. В контексте этого желания знания о том что там является сетевым менеджером, какие у него вообше есть профили, сколько и каких и-фейсов и прочая - элементарно лишние. Логичнее всего если обработчик кнопки запулит сообщение в шину, а остальные кому это интересно пусть уже разбираются как это обеспечить. Нормальное иерархическое построение абстракций, с откидыванием явно лишних знаний и действий там где это даром не упало.

> Вот именно - это должно быть в сетевом конфигураторе. А не в
> каждом сетевом приложении.

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

> Инициатор - пользователь? Кнопку в конфигураторе или опцию если конфигуратор консольный.

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

В этом плане тот же NM например вполне себе разнесен на бэкэнд (собссно network-manager), а консольный клиент и гуйные клиенты разных DE к этому интерфейсятся. И d-bus оно использует. Нокия просто это сделала легеньким, хорошо работающим и доведенным до ума. Так что юзеру не приходится вбивать 20 костылей и подпорок.

> И можно обойтись без сообщений, их обработки и демонов.

Да в принципе можно и без компьютеров обойтись. Считать на счетах и в тетрадках. Но вот боюсь я не хочу чтобы сетевой конфигуратор был единственным UI к себе, напрочь лишенным возможности взаимодействия с остальным софтом.

> У программы под рутом и так хватит привилегий для этого.

У программ под рутом хватит прав чтобы записать нули в /dev/sda, или что там у вас :). Поэтому под рутом пускаются только сильно некоторые программы, по сильно некоторым случаям.

> ХЗ все виданные мной huawei за последние лет пять именно такие. Даже
> если прикидываются обычным ppp.

А, если вы про 3G свисток, внутри любого сотового девайса есть как минимум неслабая фирмварь с протокольным стеком и каким-то юзеринтерфейсом к нему. Этот стек - большой и сложный и фирмварь весит минимум несколько мегабайтов, вполне себе будучи чем-то типа RTOS. И процов там может быть несколько. Как минимум - их там обычно два: "управляюший", с которым вы общаетесь, и "сигнальный", который делает heavy lifting. А иногда процов и больше - скажем для юзеринтерфейса бывает отдельный проц. Если к нему экран прицепить, выходит смартфон.

Вайфая это в основном не касается. Ну то-есть там чаще всего лишь небольшой сервисный процик, который сугубо гоняет данные из usb в радио и операционкой сие называть больно жирно. Свежий пример - ath9k_htc и фирмварь, недавно открытая квалкоммом на 9271 и 7010.

С сотовыми сетями все сложнее: там очень кастомный протокол, подразумевающий дофига сервисных операций всех мастей. А если юзер хочет линух пускать - его на отдельный проц только пускают, дать доступ на проц который протокольный стек крутит все сцут и не то чтобы без причин - все это многомегабайтное глюкало очень даже может околеть от тыкания палочкой, в хучшем случае с завалом неслабого куска сети :)

> Всегда найдется тот, кто прикинется что ничего не знает и знать не желает.

Ну тогда получит ВНЕЗАПНЫЙ power gating или сброс. Если его угораздило что-то обновлять, производитель получит не менее ВНЕЗАПНЫЙ возврат по гарантии от обозленного юзверя.

> Вот это верно, давно нужно унифицировать возможность отключать отдельные usb порты.

Да это вроде в стандарте даже заложено. И да, позвольте все-таки не рассматривать откровенно бажные, а то и просто malicious железки: в таких допущениях вы вообще не можете надеяться на сколь-нибудь корректную работу системы. А так вон наиболее прошаренные люди делают сотовому модулю power gating отдельным полевиком, через GPIO системного проца. Как в NEO900. Снятие питания - оспорить можно только в спортлото. Тут даже бажная и вредная железка обломится.

Ответить | Правка | Наверх | Cообщить модератору

98. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 25-Май-15, 00:48 
>> Еще раз  "Поэтому для них и не работает inotify.", для тех
>> что обновляются сами можно получить событие через inotify.
> А откуда такие сведения взяты?

Из гугла по "sysfs inotify".

> И для начала: а что вами подразумевается
> под "активностью датчика"?
> Я вижу тут как минимум 2 разные сущности:
> - Датчик где-то там внутри себя что-то делает (e.g. производит замеры).
> - Датчик принимает участие в той или иной активности на шине (e.g.
> отгружает эти замеры хосту).
> Это 2 разные вещи и как они связаны в конкретном случае -
> весьма зависит от.

С точки зрения sysfs, датчики делятся на две категории:
1. Драйвер, по мере поступления новых данных, уведомляет sysfs. Соответственно inotify для в таком случае работает.
2. Драйвер ничего не делает, пока не получит запрос. Inotify в таком случае не работает естественно. Хотя возможен следующий вариант: программы следят за таким датчиком через inotify, одной из них надоедает ждать и она делает запрос. а ответ в этом случае получат все. Частота запросов будет определяться самой нетерпеливой программой.

>> Значит и inotify для него работает.
> Хз, я бы это за данность не считал без проверки.
> Если что - я достаточно активно интересовался как это работает и имею
> заметить что сделать энумерацию доступных показометров энного типа через sysfs -
> то еще приключение. Обход большой иерархии с кучей симлинков, половина которых
> имеют свойство указывать друг на друга - те еще грабли. А
> еще и на inotify там потом подписываться... выглядит как куча головняка
> на ровном месте. На мой взгляд, такой интерфейс к показометрам -
> не предел мечтаний для апликушников, мягко говоря.

Согласен, sysfs далек от совершенства. Но его нужно улучшать, а не пытаться прятать его проблемы.

> А чего такого в том чтобы sysfs остался low-level уровнем, а эта
> штука через dbus - более high-level, где можно как-то по простому
> запросить у системы нечто типа "а какие градусники есть и что
> показывают?"

Как она определит что градусник, а что нет? Выше человек еще упоминал fan и pwm, а они очень разные бывают.

>> же придется рассчитывать на худшее и дергать 10-100 раз в секунду
>> и все параметры.
> По хорошему - программы могли бы при подписке указывать свой аппетит aka
> требования к тому как они это хотели бы. А в ответ
> можно было бы еще и по хорошему сообщить что по факту
> светит с учетом умений железа и софта. Ну и с учетом
> аппетитов потребителей показаний дергать.

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

> А сейчас в sysfs btw вообще IIRC
> для датчиков нет никаких данных о скорости с которой датчики могут
> поставлять инфо, о разрешении и прочем. Подобные данные сейчас можно вообще
> получить только или экспериментально или после чтения на даташита и/или кода
> драйвера. Догадайся сам, дорогой апликушник, что этот датчик может. Удобно :)

По тому, что в большинстве случаев скорость опроса ограничивается здравым смыслом или драйвером - если драйвер знает, что чаще чем 10 раз в секунду опрашивать данный датчик бессмысленно, то драйвер просто будет отдавать последнее значение, пока оно не устареет.

>> Ну а сеть чем вы настраиваете? Логичнее поместить этот режим как один
>> из профилей настройки сети.
> Как вариант - почему бы и нет? Ну и выставлять сие по
> свистку от D-bus со стороны того кто эти профили применяет. Да,
> вы знаете, программа которая просит самолетный режим - совершенно не обязана
> быть моим менеджером сети! Виджет с кнопочкой или там какой-то обработчик
> нажатия аппаратной кнопки - совсем не обязан быть менеджером сети или
> что-то там знать о том какие у меня профайлы, настройки и-фейсов,
> список этих и-фейсов и прочая.

Я понял вашу позицию. Не нравится мне в ней то, что поверх конфигуратора сети появляется еще один конфигуратор (виджет). Нужно вводить дополнительный согласованный формат/протокол между этими конфигураторами. Геморроя много, а смысла мало.

> Есть желание: "не излучать в эфир". Когда юзер нажал вот эту кнопку.
> В контексте этого желания знания о том что там является сетевым
> менеджером, какие у него вообше есть профили, сколько и каких и-фейсов
> и прочая - элементарно лишние. Логичнее всего если обработчик кнопки запулит
> сообщение в шину, а остальные кому это интересно пусть уже разбираются
> как это обеспечить. Нормальное иерархическое построение абстракций, с откидыванием явно
> лишних знаний и действий там где это даром не упало.

И что это реально дает? Возможность навоять свою кнопку, как в андройде? Ради одной кнопки весь этот огород? Есть варианты попроще.


>> Вот именно - это должно быть в сетевом конфигураторе. А не в
>> каждом сетевом приложении.
> Нет, вот извините. Сетевой конфигуратор не должен быть всеми мыслимыми вариантами виджетов.
> И все мыслимые комбо аппаратных кнопок он обрабатывать он не должен.
> Он - конфигуратор сети, а не куча виджетов. И не мега-обработчик
> кнопок. Этим пусть занимается кто-нибудь другой. А вот потом этот другой
> по логике вещей должен пульнуть сообщение в шину. А сетевой конфигуратор
> и прочие причастные пусть там уже дальше разбираются, получив его.

Да не нужно ничего некуда пулять - делим конфигуратор на frontend и backend. Frontend'ов может быть куча - от простых однокнопочных, до навороченных.

>> У программы под рутом и так хватит привилегий для этого.
> У программ под рутом хватит прав чтобы записать нули в /dev/sda, или
> что там у вас :). Поэтому под рутом пускаются только сильно
> некоторые программы, по сильно некоторым случаям.

Не понял, а предложенный вами kdbus значит под guest'ом работает ? :)

>> Вот это верно, давно нужно унифицировать возможность отключать отдельные usb порты.
> Да это вроде в стандарте даже заложено.

Как-то раз полдня убил - ничего не получилось :( Там в дебрях usb - хабы, в теории можно только весь хаб гасить, а не отдельные порты. Но у меня и этого не получилось.

Ответить | Правка | Наверх | Cообщить модератору

108. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 25-Май-15, 05:15 
> Из гугла по "sysfs inotify".

Ну если вы такой джедай - может подскажете где посмотреть на не очень жуткий кусок кода обхода sysfs на си, где всякие грабли - обпрыганы? Ну вот допустим я хочу найти все градусники в системе. Желательно - поняв что это за градусники и например какие у них возможные диапазоны значений. Еще лучше если оно нормально обрабатывает все ошибки всех операций.

> для в таком случае работает.

...
> делает запрос. а ответ в этом случае получат все. Частота запросов
> будет определяться самой нетерпеливой программой.

А, вот оно что. Так понятнее что вы имели в виду, спасибо.

//кстати еще спасибы за сватание мне udev, это кажется вы были. Я через него научился делать некоторые вещи относительно безграбельно и не очень криво.

> Согласен, sysfs далек от совершенства. Но его нужно улучшать, а не пытаться
> прятать его проблемы.

Не имею ничего против улучшения sysfs. Заметьте, ни я, ни гномеры не предлагали его выпилить и заменить. Они как я понимаю предлагали прослойку для апликушников пишущих десктопные программы, которым не в кассу делать кучу (около)файловых операций, проверяя^W забивая на пару десятков потенциальных ошибок в самых разных местах.

> Как она определит что градусник, а что нет?

Градусник - это то что показывает температуру, очевидно. А вот как определить - было бы неплохо если бы гномеры сделали какие-то фильтры, или типа того, чтобы каждый первый апликушник не ломал над этим голову сам.

> Выше человек еще упоминал fan и pwm, а они очень разные бывают.

Во первых, они - не градусники. Во вторых, я немного поинтересовался вопросом, когда АМДшники запиливали управление вентилем. Ну и насколько я понял - некий "стандарт" поведения там устаканился. Сам по себе PWM вполне однозначно характеризуется коэффициентом заполнения. Тут правда возможны варианты кто его меняет: железка со своей стороны, софт со своей, и как это происходит. АМДшники по этому поводу там довесок вывесили, позволяющий как уповать на авторегулирование набортным сервисным процом (по дефолту) так и самому порулить. Сам по себе коэффициент заполнения - во всех PWMах более-менее однозначная штука и как он может быть сильно по разному - ну хз.

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

Где-то сложнее. Где-то проще. Апликушнику имхо было бы проще сделать полтора обращения к гномерской приблуде чем ...цать операций с ФС и файлами, каждая из которых потенциально может обломаться.

> датчик бессмысленно, то драйвер просто будет отдавать последнее
> значение, пока оно не устареет.

И все бы замечательно. Вот только неплохо бы в принципе знать динамику и диапазоны датчика, а также что это вообще такое. Ну например чтобы понять с какой скоростью имеет смысл перерисовывать показометр. А то глупо перерисовывать 5 раз в секунду для датчика который оказывается обновляется не чаще чем 1 раз в секунду.

> Я понял вашу позицию. Не нравится мне в ней то, что поверх
> конфигуратора сети появляется еще один конфигуратор (виджет).

А я считаю что плохо когда программы - вещь в себе и не могут взаимодействовать с другими программами. Одна из сильных сторон unix way - возможность собирать систему из кубиков, соединяя их между собой. Но как видим, практика показала что не все то что люди хотят от компьютеров сейчас хорошо делается как именно файловые операции.

Собственно какой-то зачаточный IPC был много лет. Просто он был сделан в виде в котором у него сравнительно мало применений. Ну как у отсылки RAW фреймов эзернета применений здорово меньше чем скажем программ уповающих на работу с HTTP. Имхо было бы неплохо взаимодействие между программами неплохо бы расширить еще и шиной. Модель pub/sub имеет свои плюсы, а некоторые вещи так выглядят наиболее логично и позволяют стыковку самых разных программ по самым разным поводам. В несколько более структурированном виде чем остальные варианты.

> Нужно вводить дополнительный согласованный формат/протокол между этими
> конфигураторами. Геморроя много,

В случае шины это как раз получается относительно логично и относительно просто. Пример N900 тому подтверждением.

> а смысла мало.

Не согласен. Возможность воздействовать между программами, делая те или иные действия из той программы удобна мне - это хорошо и правильно. А вот прибивать все гвоздями к 1-2 программам - гм, ну мы вроде не в винде, чтобы столь глупые ограничения на использование системы вводить.

> И что это реально дает? Возможность навоять свою кнопку, как в андройде?
> Ради одной кнопки весь этот огород?

В локально этом примере - да, это дает мне возможность нажать именно ту кнопку именно так как мне будет удобно. Без залета апликушника на выписывание полновесной морды к сетевому бэкэнду.

В более глобальном масштабе это дает возможность взаимодействия между программами aka IPC в структурированном формате. Когда можно попросить кого-то сделать что-то в каком-то структурированном виде, так что это даже еще и сможет работать между несколькими разными программами.

> Есть варианты попроще.

Например?

> Да не нужно ничего некуда пулять - делим конфигуратор на frontend и
> backend. Frontend'ов может быть куча - от простых однокнопочных, до навороченных.

А как насчет возможности использовать и полноценный конфигуратор для настройки сети в разных позах, но при этом получив и удобную кнопку для того чтобы быстро заткнуть wireless? Копаться в навороченном конфигураторе для срубания wireless - очень так себе идея. Получается что нужен некий co-existence минимум 2 разных программ воздействующих на бэкэнд. А это опять же какой-то арбитраж, информирование всех причастных что конфигурация изменилась, чтобы они не глючили в поведении и отображении статусов. Ну то-есть начинается переизобретение шины...

> Не понял, а предложенный вами kdbus значит под guest'ом работает ? :)

А kdbus как таковой - самая низкоуровневая часть шины. Он сетевые интерфейсы сам по себе не дергает by design. И в /dev/sda нули не пишет. Он сообщения между программами гоняет. Само по себе это "относительно безвредная активность". Единственное что возможно, пользуясь случаем, стоило бы устроить некий редизайн dbus, раз уж есть мысль в кернел "увековечить".

> не отдельные порты. Но у меня и этого не получилось.

Сколько я себя помню - с этим всегда были какие-то непонятки. Стандарт вроде как прописывает это, но реально имеет свойство не работать. В ряде железяк вроде как Vbus просто прицеплен на +5V, спасибо если через предохранитель. Ну и отключить оно это не сможет ну хоть там что. Вообще, в usb довольно много костылей и бестолковостей, вплоть до состояния когда все начинают забивать на стандарт "потому что так удобнее". Характерный пример - удлинители USB. Стандарт вроде запрещает, но всем вроде как пофиг. Или usb-otg, который часто делается через жо...хм, обычный micro-B порт вместо эзотеричного micro-A, который никто в глаза не видел. Хоть host через micro-B вроде как и не по спекам, но кабели micro-B -> AF как бы есть.

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

112. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от Michael Shigorinemail (ok), 25-Май-15, 13:25 
> где посмотреть на не очень жуткий кусок кода обхода sysfs на си, где всякие грабли
> - обпрыганы? Ну вот допустим я хочу найти все градусники в системе.

Возможно, пригодятся sysfsutils и libsysfs (отталкивался бы от systool -c, наверное).

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

119. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от Mihail Zenkov (ok), 26-Май-15, 02:11 
> //кстати еще спасибы за сватание мне udev, это кажется вы были. Я
> через него научился делать некоторые вещи относительно безграбельно и не очень
> криво.

Всегда пожалуйста, для меня эти беседы тоже о многом заставили задуматься ;)

> Не имею ничего против улучшения sysfs. Заметьте, ни я, ни гномеры не
> предлагали его выпилить и заменить. Они как я понимаю предлагали прослойку
> для апликушников пишущих десктопные программы, которым не в кассу делать кучу
> (около)файловых операций, проверяя^W забивая на пару десятков потенциальных ошибок в самых
> разных местах.

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

>> Как она определит что градусник, а что нет?
> Градусник - это то что показывает температуру, очевидно. А вот как определить
> - было бы неплохо если бы гномеры сделали какие-то фильтры, или
> типа того, чтобы каждый первый апликушник не ломал над этим голову
> сам.

Это понятно, но как сами гномеры узнают, что есть что? Я к тому, что если это делать по нормальному, все равно придется править sysfs и драйвера. Иначе будет работать только на пяти датчиках (как в новости) до которых гномеры дотянулись и запихали в свою базу (завязанную за гном и systemd). Ведь все только выиграют, если исправить проблему на уровне ядра.

>> Выше человек еще упоминал fan и pwm, а они очень разные бывают.
> Во первых, они - не градусники. Во вторых, я немного поинтересовался вопросом,
> когда АМДшники запиливали управление вентилем. Ну и насколько я понял -
> некий "стандарт" поведения там устаканился. Сам по себе PWM вполне однозначно
> характеризуется коэффициентом заполнения.

На первый взгляд - да, но глубже получается, что нет однозначной связи между заполнением и скоростью вентилятора. Более того pwm может иметь переключение базовой частоты.

>Тут правда возможны варианты кто его меняет:
> железка со своей стороны, софт со своей, и как это происходит.
> АМДшники по этому поводу там довесок вывесили, позволяющий как уповать на
> авторегулирование набортным сервисным процом (по дефолту) так и самому порулить. Сам
> по себе коэффициент заполнения - во всех PWMах более-менее однозначная штука
> и как он может быть сильно по разному - ну хз.

Гляньте даташит на it87xx. У меня как раз пару дней назад дошли руки его нормально настроить. То, что вы назвали авторегулированием поддается настройке, притом весьма гибкой. Изначально я хотел повесить демона который бы управлял оборотами. Но не нравилось то, что в случае сбоя (зависание компьютера/kernel panic/etc) вентилятор станет не управляемым. Да и будет лишний раз дергать проц из спячки. Но глянув в даташит был приятно удивлен - гибко и надежно и без лишних демонов.

> И все бы замечательно. Вот только неплохо бы в принципе знать динамику
> и диапазоны датчика, а также что это вообще такое. Ну например
> чтобы понять с какой скоростью имеет смысл перерисовывать показометр. А то
> глупо перерисовывать 5 раз в секунду для датчика который оказывается обновляется
> не чаще чем 1 раз в секунду.

Дело за драйвером - он вполне может показывать подобные сведения через sysfs как дополнительные свойства.

> А я считаю что плохо когда программы - вещь в себе и
> не могут взаимодействовать с другими программами. Одна из сильных сторон unix
> way - возможность собирать систему из кубиков, соединяя их между собой.
> Но как видим, практика показала что не все то что люди
> хотят от компьютеров сейчас хорошо делается как именно файловые операции.

Полностью согласен. Но хочется, чтобы это было что-то действительно простое и гибкое, без overhead'а и многостраничный стандартов. Возможно kdbus и станет первым шагом.

> Собственно какой-то зачаточный IPC был много лет. Просто он был сделан в
> виде в котором у него сравнительно мало применений. Ну как у
> отсылки RAW фреймов эзернета применений здорово меньше чем скажем программ уповающих
> на работу с HTTP. Имхо было бы неплохо взаимодействие между программами
> неплохо бы расширить еще и шиной. Модель pub/sub имеет свои плюсы,
> а некоторые вещи так выглядят наиболее логично и позволяют стыковку самых
> разных программ по самым разным поводам. В несколько более структурированном виде
> чем остальные варианты.

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

> Не согласен. Возможность воздействовать между программами, делая те или иные действия из
> той программы удобна мне - это хорошо и правильно. А вот
> прибивать все гвоздями к 1-2 программам - гм, ну мы вроде
> не в винде, чтобы столь глупые ограничения на использование системы вводить.

Да, но пока эти "глупые ограничения" спасают от еще большей глупости использовать ipc для всего подряд и соединяться со всем подряд. В итоге будет как в вебе - лезешь на один сайт, а он грузит тонну мусора с других сайтов. И придется изобретать adblock для ipc ;)

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

90. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Michael Shigorinemail (ok), 24-Май-15, 11:03 
> Я не посещаю LOR

Коллега :)

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

99. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от Sluggard (ok), 25-Май-15, 01:08 
Элита в треде. Все в колхоз! ))
Ответить | Правка | Наверх | Cообщить модератору

106. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от Аноним (-), 25-Май-15, 03:55 
> Элита в треде. Все в колхоз! ))

Не знаю, никакого элитизма в этом нет. Он мне просто не нравится. Начиная от того что я считаю домен третьего уровня позором для ресурса серьезнее домашней странички Васи Пупкина, и заканчивая тем что там #$%нутые на всю голову модераторы. Плюс неудобный форум, неудобные формы в этом форуме, переклин на огораживании от анонимусов и что там еще. И несмотря на это - абсолютно ушибленная аудитория, на фоне которой опеннетчики, пожалуй, не такие уж плохие. Ну так, в сравнении...

Ответить | Правка | Наверх | Cообщить модератору

86. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от betcher (?), 24-Май-15, 07:40 
Rfkill не то?
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

105. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 25-Май-15, 03:48 
> Rfkill не то?

Как сказать? Это как кот Шреденгера. И то и не то. В принципе - он это делает. Но вопрос в том как.

Во первых, сам по себе он standalone программа. Мне не очень нравится идея выполнять внешнюю программу, сообщение в шину, анонсирующее system-wide что будет так-то и так-то было бы как-то логичнее. А там пусть менеджер сетевой конективити зовет его, если хочет (nm как-то так и делает).

Во вторых, просто #$%нуть интерфейс rfkill-ом - интерфейс то конечно #$%нется, спору нет. Но это никак не анонсируется остальным и для всех остальных это станет неожиданностью. Из под них просто грубо вышибут интерфейс без какого либо оповещения. А вот это называется словом "хреновый дизайн велосипеда".

Ответить | Правка | Наверх | Cообщить модератору

25. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 23-Май-15, 15:05 
На лоре уже обсуждали эту проблему:
https://www.linux.org.ru/forum/development/10756114
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

31. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 23-Май-15, 16:47 
>  через неработающий с sysfs inotify или

Или пофиксить наконец ай/фанотифай и неплодить лишних сущностей?
Но нет, мы не ищем легких путей! Чтобы ускорить дбас, нужно зафигачить его в ядро, а не редизайнить (как, кстати, и предлогал Линус)!! И продолжать пихать все возможное в этот самый д-бас!


Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

26. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от rob pike (?), 23-Май-15, 15:25 
У sysfs существует несколько проблем при использовании в качестве универсальной системной шины - насколько они реальны или надуманны - решайте сами, большинство обсуждалось недавно в комментариях к https://lwn.net/Articles/641275/
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

35. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 23-Май-15, 17:10 
> У sysfs существует несколько проблем при использовании в качестве универсальной
> системной  шины

...главная из которых - что оно на системную шину похоже не более чем мотороллер похож на самосвал.

Ответить | Правка | Наверх | Cообщить модератору

34. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 23-Май-15, 17:07 
Мне не нравится в этой идее то, что юзерспейсные события через sysfs не пустишь - и в результате приложение всё равно должно тащить ещё какой-то механизм. А в D-Bus можно уместить всё, даже если их будет два - один системный, другой пользовательский, то кодовая база одна и та же и логика обработки - тоже.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

44. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 23-Май-15, 18:50 
> Мне не нравится в этой идее то, что юзерспейсные события через sysfs
> не пустишь - и в результате приложение всё равно должно тащить
> ещё какой-то механизм.

Как уже отметили, sysfs - не система передачи сообщений. Это система работы с устройствами/драйверами, со своими задачами она справляется хорошо. Драйвера (за редким исключением) вообще не посылают событий, поэтому наворачивать d-bus повер sysfs очень странная идея.

> А в D-Bus можно уместить всё, даже если
> их будет два - один системный, другой пользовательский, то кодовая база
> одна и та же и логика обработки - тоже.

1. По факту системная шина реально нужна очень небольшому числу приложений.
2. У sysfs и d-bus разные задачи и каждый должен заниматься своим делом, их смешение только сделает систему еще более запутанной.

Ответить | Правка | Наверх | Cообщить модератору

48. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 23-Май-15, 19:16 
Я иду с другой стороны. Есть приложения, которые заинтересованы в событиях от датчика - вполне возможно, как-то обработанных, кстати. Из доступных механизмов D-Bus на роль такого транспорта подходит отлично - он хорошо структурирован, на события легко подписаться, и инициирует эти события юзерспейсный демон, с которым легко что-то сделать - сэмулировать событие, добавить какие-то обработки, логирование и т.д. Альтернатива здесь - только какой-то, опять-таки, юзерспейсный, самопал на сокетах или чем-то подобном, но никак не sysfs - и писать самопал, когда есть готовое рещение - глупость.

И я, честно говоря, не могу понять, кому ещё могут быть нужны сообщения от датчика кроме пользовательского приложения. Что до нужности - ох, не уверен. Подключение/отключение батареи, веб-камеры, монтирование разнообразных FS - это всё именно пользовательскому софту интересно прямо сейчас. Железные проблемы - тоже повод для реакции, скажем, торрентокачалки. А если пофантазировать насчёт того, что могло бы по этой шине ещё рассылаться - то это, например, оповещения о нехватке памяти - сейчас же, насколько я понимаю, вообще нет способа сказать приложению "мы тут в своп собираемся, может, ты можешь отдать часть памяти?". То же самое  - насчёт нагрузки процессора или, тем паче, включившегося троттлинга. И так далее, и тому подобное.

А события - они и есть события. Я не вижу смысла реализовывать в приложении один механизм чтобы узнать о том, что интернет доступен,  а другой - чтобы узнать, что руку к устройству поднесли. События должны быть унифицированы на более низких уровнях.

Ответить | Правка | Наверх | Cообщить модератору

84. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от Аноним (-), 24-Май-15, 06:45 
Более того - в sysfs датчики висят совершенно лысыми. Информации о том с какой их скоростью имеет смысл опрашивать - нет. Информации о разрешении датчика - нет. Информации о диапазонах - нет. Полезных ископаемых нет. Населена роботами.
Ответить | Правка | Наверх | Cообщить модератору

38. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  –1 +/–
Сообщение от Аноним (-), 23-Май-15, 17:16 
> Вместо того чтоб вылезать из тоннеля, продвинемся еще немного вглубь.

Ну так ты же не запилил более удачную шину для IPC, поэтому пользуются тем что есть.

> Логично.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

61. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от Michael Shigorinemail (ok), 23-Май-15, 22:17 
> Вместо того чтоб вылезать из тоннеля, продвинемся еще немного вглубь. Логично.

Ну это ж гномы. :)

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

36. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 23-Май-15, 17:13 
> Без D-BUS-то ну совершенно же никак этого невозможно было сделать.

Так вон датчики в sysfs висят. Или ты можешь напрямую по I2C с ними коммуницировать.

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

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

41. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 23-Май-15, 18:24 
> ...только это нифуя не удобно для апликух сталкивающихся с неопределенным набором датчиков
> на неизвестной системе, но желающих допустим экран вертеть по показаниям акселя.

И как это решит iio-sensors?  Как он узнает какой датчик - акселерометр? Почему тоже самое нельзя сделать в sysfs (создать отдельную директорию где будут только акселерометры)?

Ответить | Правка | Наверх | Cообщить модератору

49. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 23-Май-15, 19:19 
То есть вы предлагаете запихнуть это в ядро, хотя без малейших потерь всё можно сделать в юзерспейсе - в том числе обновлять базу устройств независимо от ядра.
Ответить | Правка | Наверх | Cообщить модератору

56. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 23-Май-15, 21:43 
Так драйвера уже в ядре. И есть уже /sys/class - добавить туда новые категории не проблема.
Ответить | Правка | Наверх | Cообщить модератору

57. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 23-Май-15, 21:45 
Ну так вы уж решите - то ли "как он узнает, какой датчик - акселерометр", то ли всё уже есть.
Ответить | Правка | Наверх | Cообщить модератору

60. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 23-Май-15, 22:15 
Я предлагаю, что бы драйвер регистрировал себя в /sys/class.
Если этого не сделать, то "как он узнает, какой датчик - акселерометр"? Будет тянуть отдельную базу, которую нужно будет обновлять вместе с ядром и не будет возможности узнать класс устройства без iio-*/systemd/d-bus?
Ответить | Правка | Наверх | Cообщить модератору

70. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 23-Май-15, 23:32 
Ну пусть регистрирует. Удобным для пользовательских приложений sysfs от этого не станет, и гибкую конфигурируемую логику не прибретёт. А так как скоростными такие штуки не бывают, лучшее, что можно для них сделать - юзерспейсный демон, который можно легко модиифцировать, отлаживать, мониторить, и который будет отдавать данные в удобном виде по стандартному интерфейсу, всё равно используемому приложениями для вагона других задач.
Ответить | Правка | Наверх | Cообщить модератору

73. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от Mihail Zenkov (ok), 24-Май-15, 00:18 
> Удобным для пользовательских приложений sysfs от этого не станет

Если поверху sysfs поставить d-bus, то что это даст? Тем более, что драйвера редко работают в режиме событий (а если и работают - есть inotify). Чем d-bus более удобен, чем чтение/запись файлов при работе с устройствами?

> гибкую конфигурируемую логику не прибретёт

А должен? Я думал, что для это задача приложения.

> А так как скоростными такие штуки не бывают, лучшее, что можно для них сделать - юзерспейсный демон, который можно легко модиифцировать, отлаживать, мониторить, и который будет отдавать данные в удобном виде по стандартному интерфейсу

Так sysfs это уже стандартный интерфейс для работы с железом. Зачем конкретно нужен этот демон?

Ответить | Правка | Наверх | Cообщить модератору

77. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Crazy Alex (ok), 24-Май-15, 01:47 
Удобен? Да всем. От того, что это таки события, а поллинг мы сваливаем на демон, до того, что он с вероятностью и так есть, и воткнуть в event loop ещё один обработчик - не проблема. И, разумеется, тем, что всё железоспецифичное мы оставляем деомну, а приложение получает логические события. Разница - как между сканкодами и кодами клавиш после всех обработок - повтора, раскладки, одиификаторов, переопределений и т.д.

И нет, конфигурация - далеко не всегда дело приложения. А лучше - чтобы вообще им не была. Канфигурация - дело DE, фреймворка, рабочей среды - в общем, всего того, что объединяет разрозненные куски кода, умеющие делать каждый своё, в целое, рассчитанные под конкретные задачи и условия пользователя. То самое tools, not policy. К примеру, приложение получает сообщение "нажали на кнопку" - а какой логикой и где был подавлен возможный дребег - это не его дело. А вот где-то в конфигурации может быть прописано, то ли реагировать на малейшее прикосновение, то ли на уверенное нажатие в секунду.

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

Ответить | Правка | Наверх | Cообщить модератору

78. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +1 +/–
Сообщение от Mihail Zenkov (ok), 24-Май-15, 02:25 
> Удобен? Да всем. От того, что это таки события, а поллинг мы
> сваливаем на демон,

Кто и как будет определять, что и как часто нужно опрашивать?

> И, разумеется, тем, что всё железоспецифичное мы оставляем деомну,

Несогласен - всё железоспецифичное - драйверу.

> а
> приложение получает логические события. Разница - как между сканкодами и кодами
> клавиш после всех обработок - повтора, раскладки, одиификаторов, переопределений и т.д.

Для этого есть драйвера или библиотеки над ними.

> И нет, конфигурация - далеко не всегда дело приложения. А лучше -
> чтобы вообще им не была. Канфигурация - дело DE, фреймворка, рабочей
> среды - в общем, всего того, что объединяет разрозненные куски кода,
> умеющие делать каждый своё, в целое, рассчитанные под конкретные задачи и
> условия пользователя. То самое tools, not policy. К примеру, приложение получает
> сообщение "нажали на кнопку" - а какой логикой и где был
> подавлен возможный дребег - это не его дело. А вот где-то
> в конфигурации может быть прописано, то ли реагировать на малейшее прикосновение,
> то ли на уверенное нажатие в секунду.

Это должно определяться в драйвере и управляться через sysfs. Для удобства пользователя можно поверху запустить gui/cli.

> А демон - нужен, именно потому что sysfs - это интерфейс для
> работы с железом. А приложению на железо начхать - оно работает
> с событиями, разделёнными на какие-то классы, имеющими какие-то свойства и т.п.

Ну получите вы те же самые свойства, но в виде сообщений - все равно их придется унифицировать и обрабатывать. Не лучше ли унифицировать все на уровне sysfs?

> И если смотреть не с точки зрения построения системы, а с
> точки зрения решения задач - нет никакого великого смысла держать железные
> события как что-то особенное, тем более - с отдельным интерфейсом.

В том и проблема, что в большинстве своем это не события. Если все перевести в события - будет большой overhead. Да и в любом случае будет overhead. Вы же не согласитесь с обычной файловой системой работать через d-bus? Так сказать в целях унификации интерфейсов ;)

Ответить | Правка | Наверх | Cообщить модератору

104. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 25-Май-15, 03:37 
> Кто и как будет определять, что и как часто нужно опрашивать?

По нормальному - сделать параметром который можно заказать. Если клиент X хочет 1 раз в секунду, а клиент Y хочет 2 раза в секунду, читаем 2 раза в секунду, но одному отдаем все отсчеты а второму через один. А если они это будут делать независимо, в хучшем случае они будут дергать датчик не 2 а 3 раза в секунду.

> Несогласен - всё железоспецифичное - драйверу.

Это идеальный случай. Реально совсем ничего не знать о свойствах железки, пределах измерений, максимальной частоте измерений и прочая - юзермоду может быть тяжко.

Вот вижу я аксель. А вот я у меня игрушечный вертолетик которым я порулить с смарта хочу, используя этот аксель. Как мне в программе понять - годятся ли хоть в первом приближении параметры акселя? Это таки специфика железки и драйвера, но их было бы неплохо узнать. В плане диапазонов значений а также скорости и латенси получения отсчетов.

> все на уровне sysfs?

Делать из ФС шину - ну совсем не просто. Как максимум получится кривой франкенштейн. Оно годится как некая low level подложка, но для обычных апликух с ним довольно много мороки, особенно когда вопрос в том "а какие градусники есть и что они показывают?".

> любом случае будет overhead. Вы же не согласитесь с обычной файловой
> системой работать через d-bus? Так сказать в целях унификации интерфейсов ;)

Мне кажется переклин на тотальной унификации интрфейсов - ведет к контрпродуктивным запрыгам по граблям, когда гвозди начинают завинчивать отверткой. В целях унификации.

Ответить | Правка | Наверх | Cообщить модератору

85. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 24-Май-15, 06:51 
> Если поверху sysfs поставить d-bus, то что это даст?

Возможность получения интересующей информации без двух десятков служебных микро-операций.

> Чем d-bus более удобен, чем чтение/запись файлов при работе с устройствами?

Тем что файловые операции и pub/sub принципиально разные вещи.

Вот например акселерометр. А вот пачка программ, которым нехило бы знать - портретный режим или ландшафтный стоит сейчас отображать.

Вы как, предлагаете всем программам переться читать аксель самим, обрабатывать его данные и на этом основании делать вывод? Или все-таки пусть один демон прожует это, а потом кому надо - данные с акселя разошлет, а кому попроще - просто кинет мсг вида "ориентация экрана изменилась".

> А должен? Я думал, что для это задача приложения.

Ага, вот ща мы будем учить читалку пдфников жевать RAW отсчеты из акселерометра чтобы понять в какую сторону рендерить текст. Самому то не смешно?!

> Так sysfs это уже стандартный интерфейс для работы с железом. Зачем конкретно
> нужен этот демон?

Затем чтобы объединять железо и приложения более высокоуровнвыми интерфейсами. Не комильфо читалке пдфников RAW отсчеты с акселя парсить!

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

100. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 25-Май-15, 01:28 
>> Если поверху sysfs поставить d-bus, то что это даст?
> Возможность получения интересующей информации без двух десятков служебных микро-операций.

Очень сомневаюсь. Приведите пример одного и второго решения.

> Вот например акселерометр. А вот пачка программ, которым нехило бы знать -
> портретный режим или ландшафтный стоит сейчас отображать.
> Вы как, предлагаете всем программам переться читать аксель самим, обрабатывать его данные
> и на этом основании делать вывод? Или все-таки пусть один демон
> прожует это, а потом кому надо - данные с акселя разошлет,
> а кому попроще - просто кинет мсг вида "ориентация экрана изменилась".

Неправильно поставлена задача. Этим программам не нужен акселерометр. Более того им не нужно знать какой сейчас режим (портретный/ландшафтный). Все что им нужно - уведомление о смене разрешения окна/экрана. За это должен отвечать xorg/wayland/mir/etc. Они же должны повернуть отдаваемое приложением изображение на нужное количество градусов.

Ответить | Правка | Наверх | Cообщить модератору

102. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Аноним (-), 25-Май-15, 03:16 
> Очень сомневаюсь. Приведите пример одного и второго решения.

Как бы вам сказать? Я пробовал сделать обход "градусников" через sysfs. И таки подзадолбался. Если гномеры попробуют это сделать менее геморно - я только за. В sysfs очень дубовый интерфейс, он сгодится если я знаю что "хочу вот именно этот датчик". А вот generic обход в произвольной системе, с пониманием что это за датчик и прочее...

> уведомление о смене разрешения окна/экрана. За это должен отвечать xorg/wayland/mir/etc.
> Они же должны повернуть отдаваемое приложением изображение на нужное количество

Ну во первых, уведомление о смене разрешения один фиг должно ехать через нечто bus-образное.

Во вторых, "просто повернуть изображение" было бы слишком просто. Де факто многие программы должны как минимум еще сделать ре-рендер документа под новый формат сторон, чтобы это не смотрелось как кусок блeвотины, явно понимая что они рендерят под другое соотношение сторон экрана.

В третьих, в гробу я видал чтобы xorg, wayland и прочие применяли решение о том когда крутить экран. Это должен делать некто иной. Работающий с акселем. Или чем там еще. И имеющий возможность высказать свое мнение о всем этом неопределенной группе подписчиков которых это может интерсовать. Ну то-есть xorg или wayland вполне могут быть одним из клиентов события "ориентация экрана изменилась", почему бы и нет. И даже что-то сделать по этому поводу. Но вот отнюдь не их дело читать RAW показания акселерометра и принимать решения об ориентации. А вот это решение - иксам, вялендам и проч. тоже надо как-то отсигналить. Ну вот по логике вещей получается что логичнее всего пхнуть сообщение в шину, а все заинтересованные узнают что экран крутанулся.

Ответить | Правка | Наверх | Cообщить модератору

117. "Разработчики GNOME представили iio-sensor-proxy 1.0 для упро..."  +/–
Сообщение от Mihail Zenkov (ok), 26-Май-15, 00:46 
>> уведомление о смене разрешения окна/экрана. За это должен отвечать xorg/wayland/mir/etc.
>> Они же должны повернуть отдаваемое приложением изображение на нужное количество
> Ну во первых, уведомление о смене разрешения один фиг должно ехать через
> нечто bus-образное.

Там уже есть своя система событий.

> Во вторых, "просто повернуть изображение" было бы слишком просто.

Не нужно усложнять, тогда все и будет просто.

>Де факто многие
> программы должны как минимум еще сделать ре-рендер документа под новый формат
> сторон, чтобы это не смотрелось как кусок блeвотины, явно понимая что
> они рендерят под другое соотношение сторон экрана.

Я же сказал - "Все что им нужно - уведомление о смене разрешения окна/экрана."
Было 800x600, стало 600x800. Программа просто заново разместит виджеты и подгонит их размер.

> В третьих, в гробу я видал чтобы xorg, wayland и прочие применяли
> решение о том когда крутить экран. Это должен делать некто иной.

Этим занимается xorg (конкретно xrandr) - только он может повернуть все окна и приложениям не придется думать под каким углом рисовать виджеты.

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

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

> Ну то-есть xorg или wayland вполне могут быть одним из
> клиентов события "ориентация экрана изменилась", почему бы и нет. И даже
> что-то сделать по этому поводу. Но вот отнюдь не их дело
> читать RAW показания акселерометра и принимать решения об ориентации. А вот
> это решение - иксам, вялендам и проч. тоже надо как-то отсигналить.
> Ну вот по логике вещей получается что логичнее всего пхнуть сообщение
> в шину, а все заинтересованные узнают что экран крутанулся.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру