Разделенные области Tmux в том же окне
Так как никто еще не ответил, и после утомительных часов поиска с помощью Google и тестирования, я получил некоторое схватывание предмета, я собираюсь ответить на это...
Так как интерфейс устройства кадрового буфера является довольно общим, в принципе могло быть больше fb устройств. Однако, поскольку драйвер VESA, который я использовал, обеспечивает прямое подключение между определенным устройством и файлом устройств кадрового буфера, не имеет смысла иметь больше из них, чем у каждого есть физические устройства.
Существует драйвер для виртуальных устройств кадрового буфера, vfb. (Отметьте: отличающийся от xvfb, который является виртуальным кадровым буфером для X), я не протестировал это сам, но можно было иметь столько fb устройств, сколько каждый хочет использовать виртуальное устройство. Я также думаю, что ничто в принципе не препятствует тому один передавать виртуальное устройство по каналу к аппаратному устройству кадрового буфера, позволяя создавать мультиплексор кадрового буфера
О соединении между кадровыми буферами и tty's: нет ни одного. Кадровый буфер просто оттянут на экран, игнорировав что-либо.
Что смутило меня, первоначально поведение программы просмотра изображений ФБР. Оказывается, что это умно проверяет, открыт ли tty, в котором это работает, или не и тянет к кадровому буферу или не согласно этому. (Вот почему это отказывается работать на основе SSH, в отличие от mplayer – это не принимает псевдотерминал.), Но подобная мультиплексору функциональность не имеет никакого отношения к самому кадровому буферу.
Если существует несколько процессов, пишущих в кадровый буфер, они не блокируют друг друга. Оказывается, что мои более ранние проблемы (катастрофические отказы и такой) использующий несколько fb программ одновременно даже не были о кадровом буфере вообще. Возьмите fbterm терминал и выполните mplayer от него:нет проблем. fbterm и fbcon терминалы и программа просмотра изображений ФБР тянут для буферизации только, когда что-то обновляется, таким образом, mplayer доминирует над экраном фактически 100% времени. Но при попытке выполнить два mplayers, Вы собираетесь получить представление, что мерцания, показывающие кадры того и другого, поскольку они пытаются потянуть к буферу, имеющему состояние состязания.
Некоторые полезные ссылки:
Я нашел лучший способ закодировать это, не запуская так много tmuxs, и она делает то, что я хочу, большую часть времени:
tmux new-window -a -n WinSplit
tmux new-session -d -s WinSplit
tmux selectp -t WinSplit
tmux split-window -v
tmux set-window-option -g window-status-current-bg blue
tmux split-window -v
tmux split-window -v
tmux select-layout even-vertical
tmux attach -t WinSplit
От man tmux:
split-window [-dhvP] [-l size | -p percentage] [-t target-pane]
[shell-command]
(alias: splitw)
Create a new pane by splitting target-pane: -h does a horizontal
split and -v a vertical split; if neither is specified, -v is
assumed. The -l and -p options specify the size of the new pane
in lines (for vertical split) or in cells (for horizontal split),
or as a percentage, respectively. All other options have the
same meaning as for the new-window command.
Поэтому вы должны поменять все ваши splitw -h на split -v для вертикального разделения.