Neppomuk's questions

Gostaria de usar meu antigo terminal VT420 como console do sistema. Adicionar portas RS232 e configurar serial-gettynão é um problema, mas: Durante anos, quase todas as distribuições Linux têm usado UTF-8 como conjunto de caracteres padrão, enquanto o VT fala apenas Latin-1 (ISO 8859-1) e o antigo DEC conjunto de caracteres multinacionais.

Então: O que posso fazer para serial-gettyusar um dos conjuntos de caracteres suportados pelo terminal? Existe uma solução fácil de implementar para isso? Minhas distros atuais são:

• OpenSuSE Salto 15.6
• OpenWRT, versão atual

Observe que o VT420 permite definir caracteres personalizados (bitmap), mas isso é um trabalho árduo.

Depois de mexer nas configurações do teclado da minha máquina OpenSuSE Leap 15.3, acabei com os fcitxapplets de teclado virtual aparecendo duas vezes na barra de tarefas:

Matar um miniaplicativo também faz o segundo desaparecer, e não consigo encontrar uma entrada de menu que me permita remover o miniaplicativo supérfluo. O seletor de miniaplicativos também me informa que o miniaplicativo em questão foi carregado duas vezes:

Então: O que devo fazer?

Depois de atualizar meu OpenSuSE Leap de 15.2 para 15.3, descobri que a tecla Compose (keycode: 135) não estava mais funcionando. Na verdade, xevjá não o reconhecia como Multi_key, mas como NoSymbol:

KeyPress event, serial 40, synthetic NO, window 0x7800001,
    root 0x561, subw 0x0, time 8470151, (923,367), root:(923,396),
    state 0x10, keycode 135 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

NB: A tecla está realmente rotulada Compose, pois faz parte de um teclado Sun Type 7. No $XKB/keycodes/evdevarquivo, eu tenho essas duas linhas de código (das quais a segunda foi desabilitada por mim, pois é para teclados de PC comuns com teclas de menu):

<COMP> = 135;
// alias <MENU> = <COMP>;

O $XKB/symbols/composearquivo foi atualizado com o seguinte bloco:

partial modifier_keys
xkb_symbols "comp" {
    key <COMP>  { type[Group1]="TWO_LEVEL", [ Multi_key, Multi_key ] };
};

A setxkbmapconfiguração atual tem a seguinte aparência:

╭─jacek@epica ~  
╰─➤  setxkbmap -print -verbose 10                                         127 ↵
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      pc105
layout:     de
variant:    pl
options:    compose:comp,terminate:ctrl_alt_bksp,altwin:meta_win,lv3:ralt_switch
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwertz)
types:      complete
compat:     complete
symbols:    pc+de(pl)+inet(evdev)+terminate(ctrl_alt_bksp)+altwin(meta_win)+level3(ralt_switch)+terminate(ctrl_alt_bksp)
geometry:   pc(pc105)
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwertz)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+de(pl)+inet(evdev)+terminate(ctrl_alt_bksp)+altwin(meta_win)+level3(ralt_switch)+terminate(ctrl_alt_bksp)"  };
        xkb_geometry  { include "pc(pc105)"     };
};

Eu posso ver a compose:compopção muito claramente. Então: O que há de errado aqui?

O makefile da minha solução (para Raspbian Buster) contém uma LDFLAGSdefinição como esta:

LDFLAGS=-L/usr/lib -L/usr/lib/arm-linux-gnueabihf

…para que a libdir padrão tenha prioridade sobre a específica da plataforma. Infelizmente, tive alguns problemas com uma das libs em /usr/lib, que era impossível de vincular por causa de uma ABI C++ desatualizada. Quando troquei os dirs, no entanto, tudo funcionou bem:

LDFLAGS=-L/usr/lib/arm-linux-gnueabihf -L/usr/lib

Geralmente, é preferível declarar libdirs dependentes de plataforma antes do universal /usr/lib? Obrigada.

ATUALIZAÇÃO: A receita correspondente é bastante padrão e diz o seguinte:

$(EXEC) : $(OBJECTS)
    $(CC) $(CFLAGS) $(OBJECTS) -o $(EXEC) $(LDFLAGS) $(LIBRARIES)

$(OBJECTS) : $(SRC)
    $(CC) $(CFLAGS) -c $(SRC)

Eu sei que há uma visão de uma linha por thread (-H), mas os threads específicos não são agrupados por processo mestre. Na verdade, eu ficaria completamente satisfeito com a única contagem de threads por processo (= quantos sub-threads algum processo cria?).

Eu encontrei um erro decorrente da falta de permissões ao usar a biblioteca CDIO para emitir um comando de ejeção para minha unidade de CD-ROM USB. Sempre recebo uma mensagem de erro como esta:

INFO: ioctl CDROM_SEND_PACKET for command PREVENT ALLOW MEDIUM REMOVAL (0x1e) failed: Operation not permitted

A ioctlchamada faz parte do cdda-playeraplicativo que chamo da seguinte forma:

cdda-player -ev /dev/sr0

Depois de dar uma olhada no código- fonte de libcdio, descobri que esta linha de código causa problemas:

int i_rc = ioctl (p_env->gen.fd, CDROM_SEND_PACKET, &cgc);

Quando executo o código como root (usando sudo), tudo funciona bem. Aqui estão as permissões para minha unidade de CD-ROM:

pi@autoradio:/import/valen/autoradio/libcdio-master $ ls -al /dev/sr0 
brw-rw----+ 1 root cdrom 11, 0 Jul  5 22:42 /dev/sr0

pi@autoradio:/import/valen/autoradio/libcdio-master $ ls -al /dev/sg0 
crw-rw----+ 1 root cdrom 21, 0 Jul  5 22:38 /dev/sg0

pi@autoradio:~ $ getfacl /dev/sr0 
getfacl: Removing leading '/' from absolute path names 
# file: dev/sr0 
# owner: root 
# group: cdrom 
user::rw- 
user:pi:rw- 
group::rw- 
mask::rw- 
other::---

O usuário pifaz parte do cdromgrupo. O ejectutilitário padrão funciona, no entanto.

Agora: Quais permissões devo definir para que a operação de ejeção funcione como um usuário comum? Obrigada.

ATUALIZAÇÃO: Aqui está a minha versão do kernel:

pi@autoradio:/import/valen/autoradio/libcdio-master $ uname -a 
Linux autoradio 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux 

Eu tenho uma unidade de CD/DVD USB 2.0, que é (entre outros casos de uso) usada para reproduzir CDs de música. Mas: A unidade parece ignorar os comandos CDROMPLAYMSF.

O host é um Raspberry Pi 3B com a versão atual do Raspbian. Estou usando libcdaudiopara reprodução de CD de áudio, que por sua vez emite os ioctlcomandos necessários, incluindo CDROMPLAYMSF.

ATUALIZAÇÃO: Mediante solicitação, posso fornecer as especificações da minha unidade, conforme cuspido pelo cd-driveutilitário de cdio:

CD-ROM drive supports MMC 3

                       Drive: /dev/cdrom
Vendor                      : MATSHITA
Model                       : CD-RW  CW-8124  
Revision                    : DA0D

Hardware                                  : CD-ROM or DVD
Can eject                                 : Yes
Can close tray                            : Yes
Can disable manual eject                  : Yes
Can select juke-box disc                  : No

Can set drive speed                       : No
Can read multiple sessions (e.g. PhotoCD) : Yes
Can hard reset device                     : Yes

Reading....
  Can read Mode 2 Form 1                  : Yes
  Can read Mode 2 Form 2                  : Yes
  Can read (S)VCD (i.e. Mode 2 Form 1/2)  : Yes
  Can read C2 Errors                      : Yes
  Can read IRSC                           : Yes
  Can read Media Channel Number (or UPC)  : Yes
  Can play audio                          : Yes
  Can read CD-DA                          : Yes
  Can read CD-R                           : Yes
  Can read CD-RW                          : Yes
  Can read DVD-ROM                        : Yes

Writing....
  Can write CD-RW                         : Yes
  Can write DVD-R                         : No
  Can write DVD-RAM                       : No
  Can write DVD-RW                        : No
  Can write DVD+RW                        : No