XCB: bitmap-bit-order в структуре Connection Setup — какой enum значений?

XCB_IMAGE_ORDER_LSB_FIRST, XCB_IMAGE_ORDER_MSB_FIRST

это значит и для image, и для bitmap сделаны одни магические значения? просто по спеку это совсем разные магические числа могут быть...
ясно спасибо.

думаю тогда можно ставить «решено».

Ага, да. В этом месте в документации они назвали чуть по-разному, но по сути одно и то же. В описании протокола они используют один и тот же enum, тем не менее:

  <enum name=«ImageOrder»>
    <item name=«LSBFirst»><value>0</value></item>
    <item name=«MSBFirst»><value>1</value></item>
  </enum>

  <struct name=«Setup»>
    <field type=«CARD8» name=«status» /> <!-- always 1 -> Success -->
    <pad bytes=«1» />
    <field type=«CARD16» name=«protocol_major_version» />
    <field type=«CARD16» name=«protocol_minor_version» />
    <field type=«CARD16» name=«length» />
    <field type=«CARD32» name=«release_number» />
    <field type=«CARD32» name=«resource_id_base» />
    <field type=«CARD32» name=«resource_id_mask» />
    <field type=«CARD32» name=«motion_buffer_size» />
    <field type=«CARD16» name=«vendor_len» />
    <field type=«CARD16» name=«maximum_request_length» />
    <field type=«CARD8» name=«roots_len» />
    <field type=«CARD8» name=«pixmap_formats_len» />
    <field type=«CARD8» name=«image_byte_order» enum=«ImageOrder» />
    <field type=«CARD8» name=«bitmap_format_bit_order» enum=«ImageOrder» />
    <field type=«CARD8» name=«bitmap_format_scanline_unit» />
    <field type=«CARD8» name=«bitmap_format_scanline_pad» />
    <field type=«KEYCODE» name=«min_keycode» />
    <field type=«KEYCODE» name=«max_keycode» />
    <pad bytes=«4» />
    <list type=«char» name=«vendor»>
      <fieldref>vendor_len</fieldref>
    </list>
    <list type=«FORMAT» name=«pixmap_formats»>
      <fieldref>pixmap_formats_len</fieldref>
    </list>
    <list type=«SCREEN» name=«roots»>
      <fieldref>roots_len</fieldref>
    </list>
  </struct>

Иногда даже может быть полезным заглядывать в xcb-xml для уточнений.

блин точно — XML исходники — отличная идея

Ну да. Имена все формируются преобразованием CamelCase в CAMEL_CASE (CAMElCase -> CAM_EL_CASE) в случае, например, enum или в camel_case в случае функций. Первое слово xcb_, потом идет название расширения xcb_render_, потом идет название запроса xcb_render_trapezoids. Ну и аргументы так же. По данной системе и получается с enum XCB_, IMAGE_ORDER и потом сами названия в структуре LSB_FIRST/MSB_FIRST.

что-то такое получилось
только не уверен, что не переделаю что-то из этого в классы.

И вообще сишные исходники (хедеры) генерятся из xml-файлов протокола python-скриптом.

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

И вообще сишные исходники (хедеры) генерятся из xml-файлов протокола python-скриптом.

Да-да, в курсе. А с самого начала, до python-скрипта, генерировали при помощи XSLT. В *.h, к сожалению, не указано, какой enum надо в поле подставлять, а в XML указано.

вопрос не по топику, но xcb гдето рядом

for(auto iter = xcb_setup_pixmap_formats_iterator(_setup); iter.rem; xcb_format_next(& iter))
      printf("pixmap formats: depth:%d, bpp:%d", iter.data->depth, iter.data->bits_per_pixel);

дает мне вывод

pixmap formats: depth:1, bpp:1  
pixmap formats: depth:4, bpp:8  
pixmap formats: depth:8, bpp:8  
pixmap formats: depth:15, bpp:16 
pixmap formats: depth:16, bpp:16  
pixmap formats: depth:24, bpp:32  
pixmap formats: depth:32, bpp:32  

можно запросить pixmap в любом этом формате через xcb_get_image или как? (чтобы отдать клиенту как он хочет без доп работы)

второй вопрос, смотрю доступные visuals например так

for(auto dIter = xcb_screen_allowed_depths_iterator(_screen); dIter.rem; xcb_depth_next(& dIter))
 {
    printf("allowed depth:%d, visuals:%d", dIter.data->depth, dIter.data->visuals_len);
    for(auto vIter = xcb_depth_visuals_iterator(dIter.data); vIter.rem; xcb_visualtype_next(& vIter))
        printf(...);
}

вижу вот это

allowed depth:24, visuals:48
visual id: 0x21, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0x22, class: 0x05, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xe9, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xea, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xeb, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xec, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xed, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xee, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xef, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf0, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf1, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf2, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf3, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf4, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf5, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf6, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf7, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf8, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xf9, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xfa, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xfb, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xfc, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xfd, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xfe, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0xff, class: 0x04, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0x100, class: 0x05, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0x101, class: 0x05, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
visual id: 0x102, class: 0x05, bits per rgb: 8, red: 00ff0000, green: 0000ff00, blue: 000000ff, color entries: 256
...
allowed depth:1, visuals:0
allowed depth:4, visuals:0
allowed depth:8, visuals:0
allowed depth:15, visuals:0
allowed depth:16, visuals:0
allowed depth:32, visuals:10
...

в чем смысл, они же одинаковы по формату?! по при этом для других depth они пустые, а как же pixmap formats?!

можно запросить pixmap в любом этом формате через xcb_get_image или как?

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

Лучше бы отдельную тему создать, но ладно.

можно запросить pixmap в любом этом формате через xcb_get_image или как? (чтобы отдать клиенту как он хочет без доп работы)

При помощи xcb_get_image ты не pixmap запрашиваешь, а image. Ты «фотографируешь» pixmap и получаешь фотографию в виде image. Глубина image должна соответствоать глубине drawable, то есть глубине window или pixmap — это объекты типа drawable.

man xgetimage:

If XYBitmap format is used, the depth of the image must be one, or a BadMatch error results. For XYPixmap and ZPixmap, the depth of the image must match the depth of the drawable, or a BadMatch error results.

The depth of the destination XImage structure must be the same as that of the drawable.

XGetImage returns the depth of the image to the depth member of the XImage structure. The depth of the image is as specified when the drawable was created, except when getting a subset of the planes in XYPixmap format, when the depth is given by the number of bits set to 1 in plane_mask.

второй вопрос, смотрю доступные visuals например так

в чем смысл, они же одинаковы по формату?!

Вопрос, почему много одинаковых? На самом деле, они не совсем одинаковые. Они разные свойства у GLX имеют. Можешь посмотреть glxinfo, где он табличку выведет по visuals.

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

вот этот вот plane mask именно для ZPixmap получается ничего не изменяет?

формат это про XY_PIXMAP или Z_PIXMAP? это план порядок битов как я понял, XY_PIXMAP это совсем чтото специфичное

эмм... а как еще сведения о системе получать?

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

как угодно ещё. уточни вопрос

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

дёрнув функцию ПолучитьИнформацию() получить структуру, содержащую поле, максимальноПоддерживаемыйУровеньСглаживания, нет?

так разные форматы поддерживаются в системе — какой хочешь, такой и выбираешь...
только в виде списка (массива) представлять такое — вот он и есть...

какие ещё форматы? тут достаточно одного числа от 0 до 16

не понял — а кто его должен высчитывать? оконная система ?

производитель видеокарты в драйвере константой пропишет, нет?

эмм...
так там снова же множество значений для разных форматов...

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

хотя достаточно просто было сделать отдельные флаги/поля для включения кажой фичи

ну ты же сам отвечаешь на свой вопрос — много комбинаций...

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

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

А с самого начала, до python-скрипта, генерировали при помощи XSLT.

Да они просто титаны духа. Генерить что-то, отличное от XML, с помощью XSLT - та еще боль.

ась? я упрощаю для примера, речь идёт про запихнутые в visuals за каким-то хреном сглаживание, depth, stencil и прочее

XY_PIXMAP это совсем чтото специфичное

Да, оно старое, для другого способа отображения и организации видеопамяти, которое сейчас не используется, но когда-то использовалось. https://en.wikipedia.org/wiki/Planar_(computer_graphics). Сейчас не имеет никакого смысла, так как GPU этот формат не понимают и ускорить не могут.

Да они просто титаны духа. Генерить что-то, отличное от XML, с помощью XSLT - та еще боль.

Ага, я как-то разбирался, что там понаписали (тогда еще python не использовали). Голову чуть-чуть сломал, но потом подлечил. https://gitlab.freedesktop.org/xorg/lib/libxcb/-/blob/1.7/src/c-client.xsl

А до XSLT и XML, с самого начала проекта, протокол описывался и разворачивался при помощи m4 macros, но в какой-то момент решили, что m4 не так уж стильно и не так уж модно. :)

https://gitlab.freedesktop.org/xorg/lib/libxcb/-/blob/1.7/src/c-client.xsl

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

Хотя немного знакомого адка присутствует, например в https://gitlab.freedesktop.org/xorg/lib/libxcb/-/blob/1.7/src/c-client.xsl#L1244-1284 - эпилептические отступы и пустые строки это не баг, а форматирование сишного кода.

А до XSLT и XML, с самого начала проекта, протокол описывался и разворачивался при помощи m4 macros, но в какой-то момент решили, что m4 не так уж стильно и не так уж модно. :)

Когда XCB появился на слуху, там уже во всю был XML, я и не думал, что его разрабатывали с 2001 года.

Нашел вот такую статью: https://jamey.thesharps.us/2021/03/25/xcb-protocol-specifications-data/

XCB’s code generation continued to be based on m4 for the next three years, until Josh Triplett took Bart’s “Open Source UNIX Software Development” class and replaced all my beautiful m4 macros with a combination of XML and XSLT. Despite that, we became good friends.

Выбор XSLT сложно обосновать чем-то, кроме моды, а вот XML-спецификация это сила. С m4-спецификацией работать можно, по большому счету, только на самом m4, а для xml понаписали сторонних обработчиков на разных языках, в т.ч. X11 клиенты для других ЯП и обработчик в wireshark. Что-то IDL-образное было бы, на мой вкус, красивее, но тогда для каждого языка пришлось бы писать отдельный парсер.

так насчет bitmap_format_bit_order == XCB_IMAGE_ORDER_LSB_FIRST это будет BGR или RGB? или это вообще не про то?

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

Поэтому написали отдельный парсер на питоне для си.

Они XML-парсер не сами писали, а взяли встроенный ElementTree.

Наводящий вопрос про важность xml: насколько просто написать парсер для c++ c шаблонами, векторами, умными указателями?

парсер

парсер протокола xcb

Берешь любую реализацию xml-парсера с нужными тебе характеристиками и парсишь

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

Кто как хочет. Чаще используют оригинальную реализацию на си, но есть и проекты вроде

https://github.com/mwitmer/guile-xcb

https://hackage.haskell.org/package/xcb-types

В wireshark по спецификации генерируют парсер X11 сообщений, для этой цели оригинальные xcb-либы вообще не предназначены

Насколько сложнее было написать аналогичные парсеры для своего idl?

Для этого нужно написать парсер самого idl, т.е. распарсить текст на токены, построить из них какое-то подобие AST, а уже потом его обходить и что-то с ним делать, аналогично тому, как работают с XML DOM. Или намешать все в одну кучу, но очевидно, что общая сложность от этого не уменьшится.

Или намешать все в одну кучу

Как это сделано в c_client.py?

написать парсер самого idl

Какие проблемы для очень узкоспециализированного dsl? Уверен, генераторов парсеров не меньше, а то и больше, чем парсеров xml.

Ты на серьезе утверждаешь, что сделать свой парсер, даже сгенерированный на основе грамматики, это тот же объем работы, что и обойти готовое DOM-дерево? Похоже на троллинг

обойти готовое DOM-дерево

Это только 1 процент работы.

Похоже на троллинг

Вот именно.

DOM-дерево

например, s-выражения намного легче парсятся и машиной и человеком, чем xml

так насчет bitmap_format_bit_order == XCB_IMAGE_ORDER_LSB_FIRST это будет BGR или RGB? или это вообще не про то?

Это относится к endianness машины. xserver/include/servermd.h:

#include <X11/Xarch.h>		/* for X_LITTLE_ENDIAN/X_BIG_ENDIAN */

#if X_BYTE_ORDER == X_LITTLE_ENDIAN
#define IMAGE_BYTE_ORDER        LSBFirst
#define BITMAP_BIT_ORDER        LSBFirst
#elif X_BYTE_ORDER == X_BIG_ENDIAN
#define IMAGE_BYTE_ORDER        MSBFirst
#define BITMAP_BIT_ORDER        MSBFirst
#else
#error "Too weird to live."
#endif