Bug 1530 - mev doesn't work correctly in non-linux vc
Summary: mev doesn't work correctly in non-linux vc
Status: ASSIGNED
Alias: None
Product: Sisyphus
Classification: Development
Component: gpm (show other bugs)
Version: unstable
Hardware: all Linux
: P5 major
Assignee: placeholder@altlinux.org
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-07 22:55 MSK by imz
Modified: 2010-10-30 11:53 MSD (History)
4 users (show)

See Also:


Attachments
deb-alt-xterm_mouse_support.patch, поправлетый (2.11 KB, patch)
2007-09-11 13:43 MSD, Alexey Voinov
no flags Details | Diff
mdk-alt-consolename.patch, поправлетый (761 bytes, patch)
2007-09-11 18:05 MSD, Alexey Voinov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description imz 2002-11-07 22:55:20 MSK
Started in a terminal other than linux VC, mev

1. sends some garbage to the terminal: it spoils the terminl\'s state;

2. doesn\'t work correctly with the -C parameter.

This makes using gpm-features in Emacs impossible (via mev called from t-mouse.el).
---
In xterm (or Eterm):

1.

$ mev
O0o.oops(): [mev.c(445)]:
/usr/bin/mev: use rmev to see gpm events in xterm or rxvt

After this try selection something with the mouse in this terminal: it prints some garbage.

2. login on a linux console (N 1), and run 

mev -C 1

in an xterm. It prints the same error message, though it should attach to that console. (The same if run a root.)

If you call it from Emacs shell (emacs -nw, then press M-x eshell), you can see what mev writes to the terminal on startup:

$ mev
^[[?1001s^[[?1000hO0o.oops(): [mev.c(445)]:
/usr/bin/mev: use rmev to see gpm events in xterm or rxvt


It happens even if emacs is run in a linux VC.
---
gpm-1.20.1-alt0.6rc1
Comment 1 Dmitry V. Levin 2003-09-06 23:30:22 MSD
Well, how it should work? 
Comment 2 Alexey Voinov 2007-09-07 13:47:32 MSD
Проблема в том, что функция no_mouse_contol из патча xterm_mouse_support
возвращает 0 только если запуск mev (Gpm_Open) происходит в "чистой"
linux-консоли. Если запускать из emacs, запущенного в linux-консоли, то функция
вернёт 1. Подозреваю, что это не только из под emacs будет проявляться. Чем
отличается /dev/tty под emacs от /dev/tty без него я не знаю. Как бы это
посмотреть? strace -o emacs.log emacs -Q не показывает какой-либо активности в
области tty.

В общем, бага всё ещё актуальна, и t-mouse так и не работает.
Comment 3 Alexey Voinov 2007-09-11 10:49:49 MSD
Значит так, патч deb-alt-xterm_mouse_support некорректен.

Во-первых, функция no_mouse_control работает только в "голой" консоли. Если
запуск программы осуществляется с псевдо-терминалом, то ioctl всегда возвращает
-1 (EINVAL). Так происходит и в xterm и в emacs.

Во-вторых, проверка на kmous, тоже не даёт ожидаемый результат. kmous есть и у
терминала linux тоже, на что, собственно, мы и наступаем. Работаем с
псевдотерминалом, kmous есть - значит вроде как xterm, а на самом деле - linux.

Наиболее приемлимым hackaround'ом тут будет, пожалуй, проверка на имя терминала,
начинающееся с linux, и если нет, то проверка на kmous. Патч сейчас изготовлю.
Возражения есть? :)
Comment 4 Alexey Voinov 2007-09-11 13:43:55 MSD
Created attachment 2191 [details]
deb-alt-xterm_mouse_support.patch, поправлетый

У меня в таком виде работает.
Из-за этого изменения слетает patch14, но я, честно говоря не очень понял смысл
этого патча. Если он действительно нужен, то могу выложить и его. У меня он уже
есть готовый.
Comment 5 Alexey Voinov 2007-09-11 18:05:10 MSD
Created attachment 2192 [details]
mdk-alt-consolename.patch, поправлетый

Как показал эксперимент, option.consolename занулять нельзя. Там есть
strlen(option.consolename), на котором замечательно сегфолтится mc. от
случайных значений мы защищены флажком check_con, так что специальное зануление
нам не требуется.
Comment 6 Michael Shigorin 2010-10-30 11:53:04 MSD
WONTFIX?