Проблема: в заглавии.

Суть: видны две сети роутера: 2.4ГГц и 5G-вариант. Подключение к первой осуществляется без проблем, а ко второй… В случае с wpa_supplicant бекендом NetworkManager’а очень долго висит на «Configuring interface…», после чего (установлено посредством вызова из nmcli) сообщает, что сеть не была найдена; в случае с iwd бекендом попытка подключения к 5G сети приводит к подключению к 2.4ГГц.

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

Отмечу, что в ходе танцевания с бубном один раз подключиться таки удалось, но после отключения повторного соединения не случилось. А может, мне просто показалось…

Подключение/переключение на Android происходит без подобных проблем. Есть идеи?

UPD: подключение/переключение на Windows также происходит без каких-либо проблем.

Есть Lutris, в нем поверх Wine-префикса установлена HotA (HoMM3).

В HD_Launcher выставлен полноэкранный режим.

После запуска игры заметно, что в полноэкранном режиме она открывается не сразу: ненадолго окно сжимается сверху и снизу.

Подобный эффект повторяется при нажатии некоторых элементов игрового интерфейса (контекстных кнопок, но не всех).

Между Wayland и X11 сессией различий в поведении не обнаружено.

При запуске в Hyprland данное поведение отсутствует.

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

В продолжение к Программирование последовательных портов (комментарий).

Установил tty0tty, который запускается при помощи systemd как модуль ядра.

Имеется виртуальная машина Booter, на которой запускается fdd (Floppy-диск с простым загрузчиком, написанным на nasm).

При помощи команд

VBoxManage modifyvm Booter --uart1 0x3F8 4 --uart-mode1=/dev/tnt0
VBoxManage modifyvm Booter --uart2 0x2F8 3 --uart-mode2=/dev/tnt1

устанавливаются настройки для последовательных портов виртуальной машины.

Имеется программа на nasm, устанавливающая системный стек, запускающая основной код и уходящая в бесконечный цикл (простой bootloader).

Проблема:

1. при первом запуске виртуальной машины программа успешно выполняется и уходит в бесконечный цикл;
2. при закрытии виртуальной машины появляется сообщение «Powering VM off», которое задерживается на 50%, после чего виртуальная машина «подвисает», но в конечном итоге закрывается через некоторое время;
3. повторный запуск этой же виртуальной машины приводит к зависанию хостовой системы (работает только курсор либо полное зависание).

Проблема появилась после того, как COM-порты виртуальной машины, привязанные к raw-файлам socat псевдотерминалов были привязаны к host-устройствам /dev/tnt*.

Сама программа выполняет пересылку байта данных из COM1 в COM2.

С чем может быть связано такое поведение?

UPD1: подключение COM1=/dev/tnt0 COM2=/dev/tnt1 для гостевой системы Linux (UART) приводит к самопроизвольным действиям в UEFI Boot menu -> UEFI Shell.

UPD2: в UEFI Shell выводятся последовательности символов, которые со времен все больше напоминают строковые константы меню VirtualBox Manager (https://imgur.com/a/GbJ0wTh).

Всем доброго времени суток.

Использую в качестве десктопа Arch, расположение дел такое:

• оконный менеджер: bspwm;
• уведомления: dunst.

Помимо всего прочего (разумеется) использую некоторые десктопные приложения, среди которых есть два основных, используемых для общения: telegram-desktop и discord.

С самого начала я заметил одну важную особенность в работе действия по умолчанию для telegram-desktop: при нажатии на уведомление (системное/встроенное) происходит смена чата на источник уведомления, но при этом не происходит фокусировка на нужном рабочем столе.

Я уже было и смирился с этим частичным неудобством, но совсем недавно заметил, что уведомления discord ведут себя иначе, а если быть более точным - так, как и должны: при нажатии на уведомление происходит переход на рабочий стол с discord-клиентом, в котором открыто нужное сообщение.

Кто-нибудь знает откуда растут ноги, руки, а также прочие конечности этой проблемы?

Добрый вечер.

Необходимо разработать две программы, взаимодействующие с последовательным портом:

1. как с файловым дескриптором;
2. непосредственно через регистры последовательного порта.

Для первого используется <termios.h>, для второго - <sys/io.h>.

Однако проверить работоспособность в двух случаях оказалось невозможно: в первом случае /dev/ttyS* и /dev/ttyUSB* попросту не открываются, а во втором всякое чтение из регистра по адресу 0x3F8 возвращает байт 255.

После такого открытия решил посмотреть доступные мне порты с помощью утилиты setserial и получил следующий результат:

❯ sudo setserial -g /dev/ttyS[0123]
/dev/ttyS0, UART: unknown, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3

~
❯ sudo setserial -g /dev/ttyUSB[01]
zsh: no matches found: /dev/ttyUSB[01]

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

Добрый день.

Имеется следующая проблема: при настройке xfce4-power-manager при помощи соответствующей графической утилиты настроил конфигурацию следующим образом:

System -> Laptop Lid

On battery -> When laptop lid is closed: Suspend
Plugged in -> When laptop lid is closed: Suspend

После такой настройки при работе от батареи при закрытии крышки перестает срабатывать переход в suspend-режим, при этом изменение настройки для режима ‘Plugged in’ на любой другой приводит к восстановлению функционала.

Кроме того, опция ‘Switch off display’ не срабатывает во всех возможных случаях.

С чем может быть связано такое поведение?

P.S.: из самодеятельности - совсем недавно прописывал `pacman -Suy’ для обновления компонентов системы.

Пользуюсь проводными наушниками (разъем jack 3.5) на ноутбуке с dual-boot системой Windows/Linux.

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

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

Вопрос: можно ли исправить проблему программными средствами (любого уровня абстракции), если да, то как?