FreeBSD Foundation спонсирует (http://docs.freebsd.org/cgi/mid.cgi?4A60D3CC.2090302) разработку более эффективного и удобного консольного драйвера (http://www.opennet.me/opennews/art.shtml?num=22600).URL: http://docs.freebsd.org/cgi/mid.cgi?4A60D3CC.2090302
Новость: http://www.opennet.me/opennews/art.shtml?num=22649
Интересный факт - FreeBSD Foundation тратит деньги в основном на престиж системы. UTF в консоли и починка паники при вытаскивании флешки - две _абсолютно_ бесполезные фичи, но только к ним и прикапывается школота, которая любит меряться осями.
юникод в консоли - не единственная причина почему syscons не оптимален. Более веской причиной будет то, что он- использует Giant mutex'ы
- нужен интерфейс для KMS (kernel mode setting)[1][2]
- нужен графический режим не только на i386[3][1] проблема ослажняется еще тем, что поддержка не-KMS драйверов постепенно уходит в прошлое. По крайней мере так обстоит дело с nouveau.
[2] с KMS наконец-то можно будет отлаживать панику, коя произошла при включенном Xorg'е без необходимости gdb через ssh/serial.
[3] надеюсь эта попытка завершится успехом в отличие от KGI и vtc(4)
Юникод идет скорее как приятное дополнение. 8-битные кодировки уже все равно никто не использует. А от консоли в основном только *требуется* нормальное отображене ASCII.
Ну да, про KMS согласен. Только в спонсируемых изменениях этим пока не пахнет.
> Только в спонсируемых изменениях этим пока не пахнетвот что rnoland@ пишет о текущем драйвере[1]
As far as KMS goes, I anticipate much of the code for
Intel/Radeon/Nouveau to be fairly portable. The tricky part is figuring
out how to hook it into our console rendering code, which I still don't
fully understand. We will also need to figure out how to handle
hardware that we don't have KMS support for.[1] http://docs.freebsd.org/cgi/mid.cgi?1247747419.1710.28.camel
Ключевая фраза - "don't fully understand". Syscons славится своейg запутанностью, как когда-то славился старый слой TTY.
ed@ упоминает KMS на второй страничке своего гранта
http://docs.google.com/gview?q=cache:rddl52TKPGkJ:80386.nl/p...
> ed@ упоминает KMS на второй страничке своего грантавот оно, один из последних пунктов:
- Implement (common) userspace API for kernel modesetting: 3 weeks.и далее:
...If we want to support features like kernel modesetting, we will always need to
invest time in writing new drivers to provide modesetting for newer graphics hardware, similar to other subsystems like the network stack.
UTF-8 (16) довольно сомнительная возможность, на мой взгляд.Юмор. Абдула, вводящий вязь справа-налево будет проклинать неверных, оставивших порядок параметров слева-направо :)))
Ну да нафиг unicode в консоли. По прежнему будем при старте Х менять локаль, вместо одной записи в /etc/login.conf. А ntfs-3g только во фре требует де факто X как зависимость. Правильно названия файлов 8.3 транслитом наше все + зоопарк разных кодировок
>Ну да нафиг unicode в консоли. По прежнему будем при старте Х
>менять локаль, вместо одной записи в /etc/login.conf. А ntfs-3g только во
>фре требует де факто X как зависимость. Правильно названия файлов 8.3
>транслитом наше все + зоопарк разных кодировокРасскажи это клиентам, работающим с всякими арабами, персами, китайцами и т.п. Если, конечно, они есть.
>I would almost suggest completely removing the userspace daemon and Sysmouse.
>With Xorg’s switch to the Hardware Abstraction Layer daemon (hald), it would be >a lot more efficient to teach it how to use USB and PS/2 mice directly.Нафиг этот HAL, оставил бы лучше как есть, ну или хотя бы два варианта.
Тут имеет место дилемма.Под FreeBSD есть замечательный devd - легкий, мощный и с удобным конфигом, поэтому мы (BSD'шники) так не любим HAL (хотя его никто не любит, на что там его уже собираются менять?) - во FreeBSD он логически лишняя сущность, вдобавок отягощенная XML, и зависимостями от какой-то слабопонятной хрени. Но не смотря на все преимущества, с devd не умеет работать xorg и DE, т.е. hal все-таки приходится использовать. Логично желание избавиться от лишних сущностей и привести hal и devd к общему знаменателю, но выкидывать devd точно никто не будет, потому что hald убог и gpl - значит, придется дописывать в devd BSD слой для совместимости с hal.
> придется дописывать в devd BSD слой для совместимости с hal.Открой для себя существование hald/freebsd/hf-devd.c
Научись читать сначала, пожалуйста.
Хм, судя по
http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/user/ed/...
шрифтом по умолчанию станет знаменитый Terminus. Наконец-то нормальный шрифт искаропки будет.
>шрифтом по умолчанию станет знаменитый Terminus. Наконец-то нормальный шрифт искаропки будет.Terminus нормален? Вы в своём уме?
Посмотрите на Apple Monaco и MS Consolas и сделайте правильные выводы.
> Посмотрите на Apple Monaco и MS Consolas и сделайте правильные выводы.TTF шрифты смотрятся ужасно без сглаживания, хинтинга и, иногда, lcd фильтрации. Сомневаюсь, что ed@ будет интегрировать freetype в свой драйвер. Впрочем, freetype доступен под BSD-like лицензией с advertise clause.
>Terminus нормален? Вы в своём уме?
>Посмотрите на Apple Monaco и MS Consolas и сделайте правильные выводы.По сравнению с этой дрянью Terminus не просто нормален, но замечателен.
Мда,от этой бородавки под названием hal уже в линуксе начинают избавляться, а его во фряху тянут за все что можно.
Расскажи мне, в пользу чего начинают отказываться от hal?
>Расскажи мне, в пользу чего начинают отказываться от hal?В сторону DeviceKit:
http://lists.freedesktop.org/archives/hal/2008-May/011560.html
http://www.ubuntu.com/testing/karmic/alpha2 -- hal deprecation started
насамом деле при правильном походе к реализации с hald все хорошо работало бы
но у вас в промежутках
xorg->hald->moused->уже драйвер в ядре
появляеться куча глюков
поэтому убрав всякие ненужные демоны и переписав консольный драйвер
возможно удасться добиться более продуктивной и слаженой работы с haldна самом деле он ничем не мешает(hald)
но вполне вероятно что рано или поздно xorg например выбросит все возможности работы с устройтвами и будет работать только через hald
вот что тогда будут делать те кто пытался избавляться от hald ?
>на самом деле он ничем не мешает(hald)Вообще-то он мешает своим наличием, особенно имея только одного consumer'а в виде xorg.
>но вполне вероятно что рано или поздно xorg например выбросит все возможности
>работы с устройтвами и будет работать только через hald
>вот что тогда будут делать те кто пытался избавляться от hald ?Надеюсь, что к тому времени hald сменят на devicekit и последний окажется не таким угрёбищем.