LINUX.ORG.RU

графический планшет, два монитора, xinput и все дела

 ,


0

1

привет, лор!
дело такое: у меня два монитора, и есть графический планшет, на котором иногда рисую всякое убожество. все бы хорошо, только при подключении планшета его курсор по умолчанию бегает по всей доступной области, т.е. по обоим мониторам (ну, как и мышь, собственно). и рабочая область планшета как бы сжимается в ширину - проще говоря, чтобы нарисовать на экране круг, надо физически рисовать овал, как-то так.
собственно, лечится это привязкой устройства ввода к конкретному монитору, благо xinput это умеет. делаю xinput list:

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech USB Optical Mouse              	id=9	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=13	[slave  pointer  (2)]
⎜   ↳ UC-LOGIC Tablet WP5540U                 	id=14	[slave  pointer  (2)]
⎜   ↳ UC-LOGIC Tablet WP5540U                 	id=15
<...> ну и дальше всякая хрень
здесь смотрим на строчки с "UC-LOGIC Tablet WP5540U"
почему два девайса создается - я хз.
дальше делаю
xinput map-to-output 14 VGA1
(для первого девайса из списка). обычно помогает. если нет - то же самое для второго (15 в данном случае). в общем-то, можно сделать сразу для обоих, это сути не меняет.
VGA1 - имя монитора из xrandr.
после этого заклинания курсор планшета привязывается к указанному монитору, т.е. края планшета = края монитора.

а теперь, уважаемые знатоки, внимание, вопрос: как бы всю эту историю автоматизировать? чтобы при подключении оно там само соображало про все координаты и прочую мурню.
топорный вариант видится таким: станцевать с бубном вокруг udev, чтобы он при появлении нужного девайса вызывал некий скрипт, который будет парсить вывод xinput list, выдергивать из него эти самые id и далее по списку. скрипт я налабаю за 10 минут, а вот в udev совершенно не умею, последний раз ковырялся в его правилах фиг знает сколько лет назад, помню только, что они пишутся на каком-то инопланетном языке))
но что, если я чего-то не знаю и есть вариант получше? может, средствами самого xinput можно как-то нашаманить? конфиг там какой создать, прописав в нем привязки к координатам... там, вроде дофига и больше всякого наворочено в ентом xinput. или на уровне иксов что-то наколдовать?

планшет Genius какой-то там, определяется как UC-LOGIC Tablet WP5540U. драйвер в ведре начиная с 2.6.38 (так и называется, uc-logic), никаких сторонних приблуд нет. вот что пишет в dmesg:
[11846.910072] usb 6-1: new low-speed USB device number 3 using uhci_hcd
[11847.114113] input: UC-LOGIC Tablet WP5540U as /devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1:1.0/0003:5543:0004.0003/input/input16
[11847.114294] input: UC-LOGIC Tablet WP5540U as /devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1:1.0/0003:5543:0004.0003/input/input17
[11847.114447] uclogic 0003:5543:0004.0003: input,hidraw2: USB HID v1.00 Mouse [UC-LOGIC Tablet WP5540U] on usb-0000:00:1d.1-1/input0

что говорит про него xinput:
>23:13:13 212 ~$ xinput list --long 14
UC-LOGIC Tablet WP5540U                 	id=14	[slave  pointer  (2)]
	Reporting 4 classes:
		Class originated from: 14. Type: XIButtonClass
		Buttons supported: 7
		Button labels: "Button Unknown" "Button Unknown" "Button Unknown" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right"
		Button state:
		Class originated from: 14. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Abs X
		  Range: 0.000000 - 32767.000000
		  Resolution: 235000 units/m
		  Mode: absolute
		  Current value: 2560.000000
		Class originated from: 14. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Abs Y
		  Range: 0.000000 - 32767.000000
		  Resolution: 323000 units/m
		  Mode: absolute
		  Current value: 0.000000
		Class originated from: 14. Type: XIValuatorClass
		Detail for Valuator 2:
		  Label: Abs Pressure
		  Range: 0.000000 - 1023.000000
		  Resolution: 0 units/m
		  Mode: absolute
		  Current value: 0.000000

>23:13:29 212 ~$ xinput list --long 15
UC-LOGIC Tablet WP5540U                 	id=15	[slave  pointer  (2)]
	Reporting 5 classes:
		Class originated from: 15. Type: XIButtonClass
		Buttons supported: 7
		Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right"
		Button state:
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Rel X
		  Range: -1.000000 - -1.000000
		  Resolution: 1 units/m
		  Mode: relative
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Rel Y
		  Range: -1.000000 - -1.000000
		  Resolution: 1 units/m
		  Mode: relative
		Class originated from: 15. Type: XIValuatorClass
		Detail for Valuator 2:
		  Label: Rel Vert Wheel
		  Range: -1.000000 - -1.000000
		  Resolution: 1 units/m
		  Mode: relative
		Class originated from: 15. Type: XIScrollClass
		Scroll info for Valuator 2
		  type: 1 (vertical)
		  increment: -1.000000
		  flags: 0x2 ( preferred )

lsusb:

Bus 006 Device 003: ID 5543:0004 UC-Logic Technology Corp. Tablet WP5540U
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x5543 UC-Logic Technology Corp.
  idProduct          0x0004 Tablet WP5540U
  bcdDevice            0.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              2 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     212
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10

PerdunJamesBond
() автор топика

почему два девайса создается - я хз.

Один - как планшет (absolute), другой - как тачпад (relative).

Кстати есть xinput set-mode <device name> ABSOLUTE|RELATIVE

И привязываться, думаю, лучше при входе в графическую сессию - прописать команду в автостарт

anonymous
()

Скрипт в автозагрузку, и всех делов.

Korchevatel ★★★★★
()

Один - как планшет (absolute), другой - как тачпад (relative).
Кстати есть xinput set-mode <device name> ABSOLUTE|RELATIVE

все равно ничего не понял)) вижу только, что один девайс отвечает за координаты и нажатие, а второй за кнопки на пере, которые имитируют мышиные. ну да ладно.
а что за моде, и что оно мне даст?

И привязываться, думаю, лучше при входе в графическую сессию - прописать команду в автостарт
Скрипт в автозагрузку, и всех делов.

не мой вариант. я его втыкаю условно говоря раз в месяц, в уже включенный комп. то есть надо ловить в момент подключения через udev. ну или прибивать гвоздями в каких-то конфигах. посмотрел - к xinput никаких конфигов не прилагается, так что, видимо, если колдовать, то через xorg.conf

PerdunJamesBond
() автор топика
Ответ на: комментарий от PerdunJamesBond

втыкаю условно говоря раз в месяц

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

andytux ★★★★★
()
Ответ на: комментарий от PerdunJamesBond

все равно ничего не понял

Ладно. И не надо. Привязывать можно только устройство, которое отдает абсолютные координаты.

через xorg.conf

Тебе хочется больше проблем, чем есть на самом деле. Думаю это невозможно. Или возможно, если через xinput list-props можно вытащить монитор, к которому привязывается. И в xorg.conf прописать Option "НайденнаяОпция" "VGA1". Чтобы привязывать именно это usb устройство, можно добавить Match MatchUSBID "Тут-ID-из-lsusb".

через udev

Думаю, будет проблема. Для привязки этот xinput будет дергать xrandr или что-то около этого, чтобы узнать размер экрана. А xrandr нужен DISPLAY, который устанавливается только после старта графической сессии. И тут я не уверен, что можно однозначно вытащить это DISPLAY.

Вывод: пиши автостарт или иконку на рабочий стол. Намного проще и работает.

anonymous
()

а теперь, уважаемые знатоки, внимание, вопрос: как бы всю эту историю автоматизировать? чтобы при подключении оно там само соображало про все координаты и прочую мурню.

никак, а то оно бы само соображало.

ЕМНИП в GNOME мапалось на primary. Раз у тебя не так, городи скрипт.

скрипт я налабаю за 10 минут, а вот в udev совершенно не умею, последний раз ковырялся в его правилах фиг знает сколько лет назад, помню только, что они пишутся на каком-то инопланетном языке))

ну так разбирайся

но что, если я чего-то не знаю и есть вариант получше?

потратить 10 минут написания шапки на разбирательство с udev.

t184256 ★★★★★
()
Ответ на: комментарий от anonymous

Как пить жопой? Никак. X-сессии на момент подключения вообще может и не быть, что ты там собрался вытаскивать?

Правило udev добавляет к устройству имя аутпута. Потребить его — задача композитора и libinput. Это если ты в 21 веке живешь. Если в 20ом и у тебя все еще иксы — та же фигня, udevом добавляется имя аутпута, а запущенный от юзера костыль мониторит события и дергает там уже какой-нибудь xinput --map-to-output $SCREEN.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

запущенный от юзера костыль мониторит события и дергает

Тогда зачем тут udev? Запущенный в *работающей графической сессии от пользователя костыль сам может мониторить появление устройств ввода (inotify /dev/input). И это костыль знает не только DISPLAY но и XAUTHORITY

anonymous
()
Ответ на: комментарий от anonymous

Тогда зачем тут udev?

Чтобы не городить

inotify /dev/input

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

Еще и форвард-совместимым путем, так что когда из дистра выкинут на мороз иксы, скрипт можно станет просто не запустить.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Чтобы не городить

А что там городить? Надо только знать, что /dev/input изменился и дергать xinput map-to-output "имя устройства" "монитор". Даже без предварительных проверок, что там изменилось.

anonymous
()
Ответ на: комментарий от t184256

Тоже вариант. Рабочий!

А вот как ты в udev собираешься без авторизации дергать чужую графическую сессию. Неужели wayland дырявее xorg?

anonymous
()
Ответ на: комментарий от anonymous

Ты другой анон что ли? Я ж русским по белому написал, что из udev я никого дергать не собираюсь, udev потегать должен и эвент послать.

Да и, боюсь спросить, что ты собрался выполнять в контексте «чужой графической сессии» в случае wayland? xinput?

t184256 ★★★★★
()
Ответ на: комментарий от t184256

udev потегать должен

Чем тегать? Именем, который уже знает пользовательский костыль?

и эвент послать.

Через dbus? Еще надо dbus присобачить?

что ты собрался выполнять в контексте «чужой графической сессии» в случае wayland?

Это тебя надо спросить: что там дергается вместо? Только не говори, что надо писать пользовательский костыль на СИ на несколько килострок.

anonymous
()
Ответ на: комментарий от anonymous

Сворачивай клоунаду.

Чем тегать? Именем, который уже знает пользовательский костыль?

OUTPUTом.

Через dbus? Еще надо dbus присобачить?

Через udev. Оно уже шлется, только без output.

Это тебя надо спросить: что там дергается вместо?

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

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от anonymous

inotify /dev/input

Вообще это супер-по-ЛОРовски.

Умные люди: вот вам механизм конфигурации вашего железа, вот вам стандартный атрибут для задания соответствия absolute input devices и outputs, вот код в mutter, который обработает все это, без привязки к конкретной графической системе, без привязки к DE, СМС и регистрации, все давно написано и код уже крутится на вашей машине. Вам осталось только прописать само соответствие, которое мы в случае с внешним планшетом знать, увы, не можем.

Анон с ЛОРа: inotify + xinput

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

Код добавления устройства ввода в композиторе.

А композитор - только бетховен (немец, это подсказка) гномовский (mutter, vater или как его там)? В любой другой композитор вполне может игнорировать тег ВЫВОД для устройства ВВОДА, как противоречивое?

anonymous
()
Ответ на: комментарий от t184256

Вообще это супер-по-ЛОРовски.

Это про тебя - суперстара. Спрашивают про xinput. И тут влезаешь ты с «xorg ненужно», «wayland - сила»

anonymous
()
Ответ на: комментарий от anonymous

А композитор - только бетховен (немец, это подсказка) гномовский (mutter, vater или как его там)?

Не знаю, знаю только что в sway почему-то осторожничают и ограничиваются маппингом встроенных, а владельцев внешних пока заставляют делать input map_to_output. Можешь спросить у них почему.

В mutter точно все от души.

В любой другой композитор вполне может игнорировать тег ВЫВОД для устройства ВВОДА, как противоречивое?

Если автор композитора имеет такую же лунную логику как и ты, то че бы и нет. Он автор, кто ж его остановит.

t184256 ★★★★★
()
Ответ на: комментарий от anonymous

Не, если вам хочется, ничего не мешает реализовать ту же логику в иксах. Может она там даже уже есть.

t184256 ★★★★★
()

в sway это очень легко делается:

input %tablet% { map_to_output %monitor% }

в иксах:

Section «InputClass» Identifier «Tablet0» MatchIsTablet «on» MatchDevicePath «/dev/input/event*» Driver «libinput» Option «координаты-бла-бла-бла (смотри название через xinput list-что-то_там) (возможно что TransformationMatrix, давно не использовал, не помню уже)» «сами координаты» EndSection

возможно после map-to-output и меняются координаты, тогда сразу можешь их взять из list-props, или же использовать калибровку (xinput_calibrator)

anonymous
()
Ответ на: комментарий от t184256

в sway почему-то осторожничают

Можешь спросить у них почему

Почему я должен спрашивать чужих о чужих проблемах?

имеет такую же лунную логику

Тот, кто втирает про тег, который имеет смысл только в единственной реализации.

anonymous
()
Ответ на: комментарий от anonymous

упс… накосячил

input %tablet% {
    map_to_output %monitor%
}

Section "InputClass"
	Identifier "Tablet0"
	MatchIsTablet "on"
	MatchDevicePath "/dev/input/event*"
	Driver "libinput"
	Option "координаты-бла-бла-бла (смотри название через xinput list-что-то_там) (возможно что TransformationMatrix, давно не использовал, не помню уже)" "сами координаты"
EndSection
anonymous
()
Ответ на: комментарий от anonymous

Пруф чего, что знать, какой absolute output device к какому output относится — хорошая идея? Нет, это слишком очевидно.

То, что эта функциональность в libinput заложена? libinput_device_get_output_name существует, хоть и, оказывается, deprecate’нут. Не знал.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Не знал.

Это как по телевизору «диалоги о …», когда ведущий толкает «монолог» - диалог с самим собой. По форме - это очень уныло, а по содержанию - спасает, только если есть информативное содержание. А его нет.

anonymous
()
Ответ на: комментарий от t184256

Вот что ты полезного сказал? При этом, многое, что сказал, опровергается. Даже сам себя опровергаешь. Да еще, все, что говоришь, это оффтопик для этой темы. Хорошо бы проверить про то, что mutter обрабатывает тег, про который говоришь.

Хотя, один тезис, вполне правдоподобен:

Вообще это супер-по-ЛОРовски.

anonymous
()

за комменты про вяленд (и сопутствиющие баталии "вяленд vs иксы") всем спасибо, но муттер-шмуттер - это вообще не мой случай. у меня старая система (условно, дебиан оооооолдштабле), на которой вяленда не может быть даже теоретически.
про udev: я вас правильно понял, что запущенный из юдева скрипт не сможет без трехэтажной шаманской магии прицепиться к пользовательской икс-сессии из-за мороки с xauthority и прочим говном?
кто там переживал, что в момент определения девайса может еще не быть иксов - с этим как раз все просто, я планшет втыкаю всегда в загруженную систему.

в иксах:
Section «InputClass» Identifier «Tablet0» MatchIsTablet «on» MatchDevicePath «/dev/input/event*» Driver «libinput» Option «координаты-бла-бла-бла (смотри название через xinput list-что-то_там) (возможно что TransformationMatrix, давно не использовал, не помню уже)» «сами координаты» EndSection
возможно после map-to-output и меняются координаты, тогда сразу можешь их взять из list-props, или же использовать калибровку (xinput_calibrator)

о, а вот за это гран мерси, друг анон! TransformationMatrix само по себе выглядит похожим на то, что мне надо. конфигурация не меняется, по ширине разрешение обоих экранов одинаковое, так что можно тупо поставить 0.5 где надо и посмотреть, что будет.
за наводку про list-props тоже спасибо! сравню до и после map-to-output, может, чего удастся выцепить полезного.

PerdunJamesBond
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.