LINUX.ORG.RU

Сообщения eve

 

Курсор мыши стал двигаться плавно

После очередного обновления пакетов (voidlinux), указатель на экране вдруг стал плавно перемещаться, как будто координаты через ФНЧ прогоняются. Крайне неудобно теперь пользоваться тачпадом (мышь не проверял, нет под рукой).

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

У меня установлен xorg. Попробовал добавить в /etc/X11/xorg.conf.d файл 50-mouse-acceleration.conf, как описано здесь:

Section "InputClass"
	Identifier "My Mouse"
	MatchIsPointer "yes"
	Option "AccelerationProfile" "-1"
	Option "AccelerationScheme" "none"
	Option "AccelSpeed" "-1"
EndSection

#Section "InputClass"
#	Identifier "My Mouse"
#	Driver "libinput"
#	MatchIsPointer "yes"
#	Option "AccelProfile" "flat"
#	Option "AccelSpeed" "0"
#EndSection

Пробовал оба варианта. Если перезагрузить комп, то курсор на несколько секунд начинает двигаться нормально, потом снова с замедлением.

В чём может быть дело?

 , ,

eve
()

Pixman. То ли лыжи не едут, то ли что

Использую библиотеку pixman. Обнаружилась какая-то странность с операцией OVER, как-то не так она смешивает цвета.

Допустим, есть изображение, закрашенное в красный цвет полностью:

pixman_image_t *img = pixman_image_create_bits(PIXMAN_a8r8g8b8, 100, 100, NULL, 0);
pixman_color_t red = { 0xffff, 0x0000, 0x0000, 0xffff };
pixman_image_fill_rectangles(PIXMAN_OP_SRC, img, &red, 1, &(pixman_rectangle16_t) { .x = 0, .y = 0, .width = 100, .height = 100 });

Дальше сверху рисую квадрат, у которого альфа = 0, а компонент синего = 255:

pixman_color_t color = { 0x0000, 0x0000, 0xffff, 0x0000 };
pixman_image_fill_rectangles(PIXMAN_OP_OVER, img, &color, 1, &(pixman_rectangle16_t) { .x = 50, .y = 50, .width = 10, .height = 10 });

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

Нужно такое смешивание:

dst = src_alpha * src + (1 - src_alpha) * dst

 

eve
()

Странности работы с /dev/hidraw

Всем привет. Кто-нибудь сталкивался с такой проблемой, что когда отправляешь пакет данных в /dev/hidraw* в N байт (т. е. столько, сколько указано в Endpoint Descriptor, значение wMaxPacketSize), а потом смотришь в Wireshark, там почему-то только N-1 байт передано.

Так оно в Linux, под Windows же всё работает прекрасно. Использовал библиотеку hidapi.

Пробовал также для приёма и передачи данных использовать обычные функции read, write из unistd.h, но проблема не устранилась.

Вот какие дескрипторы показывает lsusb, если это поможет:

 Endpoint Descriptor:
   bLength                 7
   bDescriptorType         5
   bEndpointAddress     0x81  EP 1 IN
   bmAttributes            3
     Transfer Type            Interrupt
     Synch Type               None
     Usage Type               Data
   wMaxPacketSize     0x0040  1x 64 bytes
   bInterval               1
 Endpoint Descriptor:
   bLength                 7
   bDescriptorType         5
   bEndpointAddress     0x02  EP 2 OUT
   bmAttributes            3
     Transfer Type            Interrupt
     Synch Type               None
     Usage Type               Data
   wMaxPacketSize     0x0040  1x 64 bytes
   bInterval               1

 ,

eve
()

OpenGL, проблема с графиком поверхности

Всем привет. Хочу нарисовать примерно такой график: ссылка. Вот обратите внимание на структуру поверхности, там цвет прямоугольников меняется ступенчато. Так вот, я хочу достичь такого же результата, но при этом не задавать цвета явно для каждой вершины (через VAO/VBO), а вычислять их на лету во фрагментном шейдере, в зависимости от значения Z.

И тут возникла такая проблема, посмотрите скриншот: https://ibb.co/QPpp1RB, wireframe: https://ibb.co/8NVTZZV. Получается такая вот ромбовидность.

Вот код шейдеров.

#version 330 core

uniform  mat4 u_mvp;
in       vec3 a_pos;
flat out vec3 vertex;

void main()
{
    vertex = a_pos;
    gl_Position = u_mvp * vec4(a_pos.xyz, 1.0f);
}

#version 330 core

flat in vec3 vertex;

vec3 get_color(float x)
{
    float t = (tanh(x) + 1) * 0.5f;
    vec3  a = vec3(0.0f, 0.0f, 1.0f);
    vec3  b = vec3(1.0f, 1.0f, 1.0f);
    return mix(a, b, t);
}

void main()
{
    gl_FragColor = vec4(get_color(vertex.z), 1.0f);
}

Почему так происходит? Как это можно исправить или сделать по-другому? Я только недавно стал заниматься комп. графикой, так что не судите :)

 

eve
()

Когда Kbuild/Kconfig перепишут на meson?

Чтобы можно было сгенерировать compile_commands.json для ядра и комфортно перемещаться по исходникам, например, используя emacs + ccls.

Я знаю, что compile_commands можно создать с помощью scripts/clang-tools/gen_compile_commands.py, но для этого предварительно нужно ядро собрать, на что могут уйти часы.

Кто-то может возразить, что meson на написан на петоне, поэтому ненужен. Возможно. Но ведь в ядре и так уже куча скриптов на нём, так что терять уже нечего.

 , ,

eve
()

Сборка пакетов в voidlinux

Речь идет об использовании xbps-src. Хочу, например, собрать emacs. Конкретно, emacs-x11.

$ ./xbps-src -N pkg emacs-x11

Казалось бы, все нормально, но кроме чистого emacs ещё будет собираться всякая срань вроде rust, gtk+3 и другой хлам. И уже какой час жду, когда сраст наконец соберется. Причем он нужен для сборки всего лишь одной зависимости - librsvg - которая в итоге даром не нужна.

И это только один пример, подобным образом много какие пакеты собираются.

Почему так плохо сделано? Ещё не успел перейти на void, но начинаю разочаровываться. Сравнивать могу разве что с портами в freebsd, где нет такого безобразия. Да и настраивать их там проще: make config-recursive.

Или я что-то не так делаю?

cast @Iron_Bug.

 ,

eve
()

Kernel headers в voidlinux

Не могу сообразить, почему пакет kernel-libc-headers версии 4.19.0, тогда как текущая версия самого ядра уже 5.8.14.

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

 ,

eve
()

Переходит в ждущий режим, хотя acpid выключен

В общем, странная проблема. Void Linux, ядро 5.8.9. Выключил службу acpid. Но ноутбук упорно переходит в ждущий режим при закрытии крышки. Но не всегда, что характерно. В dmesg при этом такие записи:

2020-09-15T03:48:48.98048 kern.info: [13369.081190] PM: suspend entry (deep)
2020-09-15T03:48:49.15038 kern.info: [13369.251259] Filesystems sync: 0.170 seconds
kern.info: [13369.252197] Freezing user space processes ... (elapsed 0.001 seconds) done.
kern.info: [13369.253923] OOM killer disabled.
kern.info: [13369.253924] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
kern.info: [13369.255228] printk: Suspending console(s) (use no_console_suspend to debug)
kern.notice: [13369.303815] sd 0:0:0:0: [sda] Synchronizing SCSI cache
kern.notice: [13369.330281] sd 0:0:0:0: [sda] Stopping disk
kern.info: [13369.606824] ACPI: EC: interrupt blocked
kern.info: [13369.630891] ACPI: Preparing to enter system sleep state S3
kern.info: [13369.632049] ACPI: EC: event blocked
kern.info: [13369.632051] ACPI: EC: EC stopped
kern.info: [13369.632052] PM: Saving platform NVS memory
kern.info: [13369.632347] Disabling non-boot CPUs ...
kern.info: [13369.633934] smpboot: CPU 1 is now offline
kern.info: [13369.635875] smpboot: CPU 2 is now offline
kern.info: [13369.637806] smpboot: CPU 3 is now offline
kern.warn: [13044.323586] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -837171438. Restoring
kern.info: [13369.640029] ACPI: Low-level resume complete
kern.info: [13369.640250] ACPI: EC: EC started
kern.info: [13369.640252] PM: Restoring platform NVS memory
kern.info: [13369.641551] Enabling non-boot CPUs ...
kern.info: [13369.641774] x86: Booting SMP configuration:
kern.info: [13369.641778] smpboot: Booting Node 0 Processor 1 APIC 0x2
kern.info: [13369.643627] CPU1 is up
kern.info: [13369.643760] smpboot: Booting Node 0 Processor 2 APIC 0x4
kern.info: [13369.645577] CPU2 is up
kern.info: [13369.645655] smpboot: Booting Node 0 Processor 3 APIC 0x6
kern.info: [13369.647553] CPU3 is up
kern.info: [13369.648316] ACPI: Waking up from system sleep state S3
kern.info: [13369.767241] ACPI: EC: interrupt unblocked
kern.err: [13369.767286] pci 0000:00:0f.2: can't change power state from D3cold to D0 (config space inaccessible)
kern.err: [13369.767359] pci 0000:00:0f.1: can't change power state from D3cold to D0 (config space inaccessible)
kern.info: [13369.793887] ACPI: EC: event unblocked
kern.notice: [13369.805227] sd 0:0:0:0: [sda] Starting disk
kern.info: [13370.009717] r8169 0000:02:00.0 enp2s0: Link is Down
kern.info: [13370.070244] usb 1-8: reset full-speed USB device number 4 using xhci_hcd
kern.info: [13370.274789] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
kern.info: [13370.282411] ata2.00: configured for UDMA/33
kern.info: [13370.310148] usb 1-7: reset high-speed USB device number 3 using xhci_hcd
kern.info: [13371.730682] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
kern.info: [13371.792389] ata1.00: configured for UDMA/133
kern.info: [13371.818413] OOM killer enabled.
kern.info: [13371.818414] Restarting tasks ... done.
kern.warn: [13371.824532] thermal thermal_zone1: failed to read out thermal zone (-61)
kern.info: [13371.833413] Bluetooth: hci0: read Intel version: 370810011003110e00
kern.info: [13371.833568] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
kern.info: [13371.952409] PM: suspend exit
kern.err: [13372.146166] Bluetooth: hci0: unexpected event for opcode 0xfc2f
kern.info: [13372.165244] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated

При в этом с Debian (установлен рядом) такой проблемы нет, то есть если выполнить

# systemctl mask suspend.target

– то перехода и спящий не будет. Может, в Void ядро плохое? В Debian версия младше.

 ,

eve
()

Рисование электронных цифровых схем

Подскажите, в чем можно нарисовать такого вида схемы:

https://images.app.goo.gl/Uaq7NWkcEu72SmMu7

 

eve
()

musl + gdb

musl изменяет стек так, что gdb от этого крышу сносит. В итоге, в выводе backtrace не отображаются символы, только адреса. Может, кто-нибудь подскажет, как решить? Вроде как @Iron_Bug использует musl. Всё на debian, musl 1.1.21.

Добавлю, что при статической сборке результат тот же.

Пробовал делать breakpoint на функцию abort (собственно, мне нужно отлавливать сработавшие assert-ы, а abort вызывается из assert), тогда gdb показывает символы, но только если assert() вызван из главного потока. Если из других – gdb показывает только адреса.

 ,

eve
()

Подскажите классификацию структур данных

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

Можно представлять список таким образом:

struct integer_list_node
{
    int data;
    struct integer_list_node *next;
    struct integer_list_node *prev;
};

К примеру, так реализованы списки (и другие структуры данных) в C++.

А можно так:

struct list
{
    struct list *next;
    struct list *prev;
};

struct integer_list_node
{
    int data;
    struct list node;
};

При этом обычно используют макрос типа container_of, чтобы по указателю на list получить указатель на контейнер. Так, например, списки используются в ядре Linux.

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

 ,

eve
()

RSS подписка на новые темы