Иногда графический интерфейс реагирует медленно или вообще не отвечает или кажется, что происходит сбой, но курсор по-прежнему реагирует быстро. Как работает указатель мыши?
Puede dejar las líneas que comienzan con A1como están y volver a organizar -las que comienzan conB1
# if -E or -r is not supported: sed 's/\(B1:.*\)\(A1:.*\)/\2 \1/' ip.txt
$ sed -E 's/(B1:.*)(A1:.*)/\2 \1/' ip.txt
A1: abc.com B1: Hi there
A1: gml.com B1: Your Test mail
A1: hml.com B1: Your new mail
A1: def.com B1: Test email
A1: yml.com B1: hello world
.*es codicioso, por lo que esta solución asume queA1:yB1:son únicos en cada línea(B1:.*)(A1:.*)son dos grupos de captura -para satisfacer la expresión completa, el primero capturará todas las cadenas desdeB1:hasta justo antes deA1:. El segundo capturará la cadena desdeA1:hasta el final de la línea\2 \1re -organizar las cadenas capturadas con espacio entre ellas- Lecturas adicionales:https://www.gnu.org/software/sed/manual/sed.html#Back_002dreferences-and-Subexpressions
conawk
$ awk -F'A1:' '{print $1 ~ /B1:/ ? FS $2 " " $1 : $0}' ip.txt
A1: abc.com B1: Hi there
A1: gml.com B1: Your Test mail
A1: hml.com B1: Your new mail
A1: def.com B1: Test email
A1: yml.com B1: hello world
Si el primer campo contiene B1:, vuelva a -organizar los campos, de lo contrario, imprima la línea de entrada como está
Здесь как минимум две отдельные детали:
- Аппаратный курсор
- Обновления курсора намеренно имеют приоритет
1. Аппаратный курсор
Первая деталь более -известна. Вы можете найти упоминание об этом в документации :опция HWCursorв Xorg.
Возможно, ваша графика использует аппаратный курсор. Когда аппаратное обеспечение сканирует пиксели на дисплей, оно накладывает курсор мыши поверх основного буфера кадра.
- Ошибка в графическом драйвере может привести к неправильной -настройке фреймбуфера без нарушения работы аппаратного курсора.
- Или неверно -сконфигурированный аппаратный курсор может оказаться поврежденным. Но вы все еще можете видеть, как поврежденный курсор движется и отвечает, в то время как остальная часть дисплея выглядит сломанной.
- Или курсор может быть неправильно -настроен, в то время как кадровый буфер в порядке. Как и в случае "исчезновение мыши ".
1.1 Программный курсор
Обратите внимание, что хотя аппаратные курсоры очень полезны, существуют также методы улучшения работы программных курсоров.
https://www.x.org/wiki/Development/Documentation/InputEventProcessing/
If it is done in software, the cursor has to be back-buffered. Every time it moves we restore the previous image, save the window at the target position, then render the cursor into the stream.
xorg-server-1.20.5/mi/midispcur.c - miDCSaveUnderCursor() / miDCRestoreUnderCursor()
2. Обновления курсора преднамеренно имеют приоритет
Справедливости ради следует отметить, что курсор относительно прост. Кроме того, он находится в постоянном использовании. Это означает, что конкретная память курсора -вряд ли будет выгружена, когда у вас закончится память. Но есть и другая деталь:
https://who-t.blogspot.com/2016/09/input-threads-in-x-server.html
Previously, there were two options for how an input driver would pass on events to the X server: polling or from within the signal handler. Polling simply adds all input devices' file descriptors to a select(2) loop that is processed in the mainloop of the server. The downside here is that if the server is busy rendering something, your input is delayed until that rendering is complete. Historically, polling was primarily used by the keyboard driver because it just doesn't matter much when key strokes are delayed. Both because you need the client to render them anyway (which it can't when it's busy) and possibly also because we're just so bloody used to typing delays.
The signal handler approach circumvented the delays by installing a SIGIO handler for each input device fd and calling that when any input occurs. This effectively interrupts the process until the signal handler completes, regardless of what the server is currently busy with. A great solution to provide immediate visible cursor movement (hence it is used by evdev, synaptics, wacom, and most of the now-retired legacy drivers)
[...]
The drivers push events into the queue during the signal handler, in the main loop the server reads them and processes them. In a busy server that may be several seconds after the pointer motion was performed on the screen but hey, it still feels responsive.
[...]
We were still mostly "happy" with it until libinput came along. libinput is a full input stack and expecting it to work within a signal handler is the somewhere between optimistic, masochistic and sadistic. The xf86-input-libinput driver doesn't use the signal handler and the side effect of this is that a desktop with libinput didn't feel as responsive when the server was busy rendering.
Keith Packard stepped in and switched the server from the signal handler to using input threads. Or more specifically: one input thread on top of the main thread. That thread controls all the input device's file descriptors and continuously reads events off them. It otherwise provides the same functionality the signal handler did before: visible pointer movement and shoving events into the event queue for the main thread to process them later. But of course, once you switch to threads, problems have 2 you now. [...] some interesting race conditions kept happening. But as of today, we think most of these are solved.