LINUX.ORG.RU

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

 ,


0

1

в спецификации Xorg указано:

bitmap-bit-order: { LeastSignificant, MostSignificant }


однако такого enum я не нашел в XCB.
его и правда нет, либо как то странно называется?

ответ

★★

Ответ на: комментарий от Zubok

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

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

safocl ★★ ()
Ответ на: комментарий от safocl

Ага, да. В этом месте в документации они назвали чуть по-разному, но по сути одно и то же. В описании протокола они используют один и тот же 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 для уточнений.

Zubok ★★★★★ ()
Ответ на: комментарий от safocl

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

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 3)
Ответ на: комментарий от anonymous

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

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

Zubok ★★★★★ ()
Ответ на: комментарий от Zubok

вопрос не по топику, но 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?!

anonymous2 ★★★★★ ()
Последнее исправление: anonymous2 (всего исправлений: 2)
Ответ на: комментарий от anonymous2

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

можно запросить 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.

Zubok ★★★★★ ()
Ответ на: комментарий от anonymous2

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

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

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

Zubok ★★★★★ ()
Ответ на: комментарий от safocl

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

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

anonymous ()
Ответ на: комментарий от anonymous2

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

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

Zubok ★★★★★ ()
Ответ на: комментарий от annulen

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

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

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

Zubok ★★★★★ ()
Ответ на: комментарий от Zubok

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-образное было бы, на мой вкус, красивее, но тогда для каждого языка пришлось бы писать отдельный парсер.

annulen ★★★★★ ()
Ответ на: комментарий от annulen

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

annulen ★★★★★ ()
Ответ на: комментарий от anonymous

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

annulen ★★★★★ ()
Ответ на: комментарий от annulen

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

annulen ★★★★★ ()
Ответ на: комментарий от anonymous2

так насчет 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
Zubok ★★★★★ ()