Menu
▾
▴
linuxconsole-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(235) |
Apr
(30) |
May
(32) |
Jun
(86) |
Jul
(81) |
Aug
(108) |
Sep
(27) |
Oct
(22) |
Nov
(34) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(78) |
Feb
(10) |
Mar
(81) |
Apr
(27) |
May
(13) |
Jun
(105) |
Jul
(78) |
Aug
(52) |
Sep
(59) |
Oct
(90) |
Nov
(127) |
Dec
(49) |
| 2002 |
Jan
(102) |
Feb
(72) |
Mar
(54) |
Apr
(98) |
May
(25) |
Jun
(23) |
Jul
(123) |
Aug
(14) |
Sep
(52) |
Oct
(65) |
Nov
(48) |
Dec
(48) |
| 2003 |
Jan
(22) |
Feb
(25) |
Mar
(29) |
Apr
(12) |
May
(16) |
Jun
(11) |
Jul
(20) |
Aug
(20) |
Sep
(43) |
Oct
(84) |
Nov
(98) |
Dec
(56) |
| 2004 |
Jan
(28) |
Feb
(39) |
Mar
(41) |
Apr
(28) |
May
(88) |
Jun
(17) |
Jul
(43) |
Aug
(57) |
Sep
(54) |
Oct
(42) |
Nov
(32) |
Dec
(58) |
| 2005 |
Jan
(80) |
Feb
(31) |
Mar
(65) |
Apr
(41) |
May
(20) |
Jun
(34) |
Jul
(62) |
Aug
(73) |
Sep
(81) |
Oct
(48) |
Nov
(57) |
Dec
(57) |
| 2006 |
Jan
(63) |
Feb
(24) |
Mar
(18) |
Apr
(9) |
May
(22) |
Jun
(29) |
Jul
(47) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Vojtech P. <vo...@su...> - 2002-03-10 18:14:42
|
On Sat, Mar 02, 2002 at 11:21:40PM +0100, Alexander Rawass wrote: > What has stopped working is my old-analogue joystick: > > [root@jungle /root]# modprobe ns558 > /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: init_module: No > such device > Hint: insmod errors can be caused by incorrect module parameters, including > invalid IO or IRQ parameters > /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod > /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o failed > /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod ns558 failed > > Before I used 2.4.12, I tried using 2.4.2 with it's non-force-feedback > 'iforce' drivers. > > With 2.4.2, my analogue joystick became js0 and the Pegasus was js1. > > Now, with 2.4.12, the loading of ns558 doesn't work anymore - I dunno why? > > I don't think that's a problem with the force-feedback-drivers - any idea why > it doesn't want my ns558 module (haven't changed anything in BIOS or > interrupts). > > See here my loading script: > > echo "Loading Sound modules" > > modprobe es1371 joystick=0x200 > > echo "Loading Joystick modules" > > modprobe joydev # userland interface > modprobe ns558 # gameport driver > modprobe analog # analog-joystick > > modprobe serio > modprobe serport > modprobe iforce > modprobe evdev > > /usr/local/bin/inputattach --iforce /dev/ttyS1 & > > > Any ideas or comments? > > I'll hope I'll be able to update on 2.4.17 soon. In 2.4.12 you shouldn't need the ns558 module anymore, the functionality to register a gameport is included in es1371 already. What does 'dmesg' say? -- Vojtech Pavlik SuSE Labs |
|
From: <dol...@cl...> - 2002-03-09 11:01:54
|
Hello all, I was wondering what was the current status of Ruby on PowerPC, is it known (not) to work ATM ? I haven't tried it in a while, sorry :-( Also, what is the "official" tree when working on Ruby ? I'd like to resume work on the ruby-fied pm3fb (the old-fashioned one is now integrated as of 2.4.19-pre1). For some reason, I believed the DJ tree was the one, but it doesn't compile on my box (stuff totally unrelated to input or FB). I didn't try any other 2.5.x. Thanks in advance for any pointer/advice, -- Romain DOLBEAU | For a hill, men would kill, ENS Cachan / Ker Lann | Why ? They do not know. Thesard IRISA / CAPS | -- Metallica, dol...@cl... | 'For Whom The Bell Tolls' |
|
From: Johann D. <de...@if...> - 2002-03-06 23:13:14
|
Hi, I've just committed a few changes to the hid code. Few changes on the existing files, most of the code is situated in the newly added hid-ff.c file. Please have a look at these files and make comments on the way I chose to leave room for other force-feedback protocol implementations. I also copied the Makefile and Config.* files from kernel 2.5.5-dj1. As those files had last been touched when kernel 2.5.1 went out, I guess the parts that were missing from the files in the CVS tree were additions we missed (and not removal done on purpose). ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif |
|
From: TR L. <tr...@jo...> - 2002-03-06 19:10:54
|
Hi, I want to discuss a problem of the keyboard driver implementation in the current input driver. It might be not a problem but my misunderstanding. Each key event has a meaning. This means each event has an expected action. For example, KEY_POWER causes the system to be shutdown. If we apply this rule to others, KEY_F will be translated eventually to a character 'F'. This means event handlers only have to focus on the meaning of the event and do not require other information. At the same time keyboard driver writers can know or expect what will happen if he reports certain key event. But I think this is not the case for the current input driver. Current key events seem to be defined assuming that all keyboards have English QWERTY layout and scancodes are converted based on this assumption. This makes a problem for people who use a keyboard with a different non-hardwired layout(dvorak?). For those people, there has to be a mechanism to translate each key event to the desired action(generating characters mostly). But if we implement this as an input handler, KEY_F won't result an easily expectable action anymore but it can be translated to 'U' not 'F' with different key layout. This adds a complexity to both key input handlers and key input drivers. Since key events cannot be handled as it is, handlers need additional information on the key layout. Keyboard drivers also have to know what is the current key layout to generate desired character(action). This can be a problem for special purpose, non-standard(?) keyboards and keypads which have only small set of keys. If this is not wanted, I think providing user configurable mechanism for mapping scancodes to key events and implementing it in the keyboard driver layer like atkbd.c is the most desirable. What do you think? w/ regards, TR Lim tr...@jo... |
|
From: Hu Y. <ccp...@et...> - 2002-03-06 02:45:21
|
I am working on zhcon, the CJK virtual console project. We are keeping eyes on linux console. I guess the chinese display should work in kernel soon, next problem is the input core. So we are talking about that, which should be implement by kernel if we want to get chinese input function. Or you may tell us how linux-console think about chinese support? > > ----- Original Message ----- > From: "Rodrigo Damazio" <cu...@uo...> > Cc: "linuxconsole-dev" <lin...@li...> > Sent: Wednesday, March 06, 2002 9:53 AM > Subject: Re: module or daemon > > > > I would guess he wants help getting chinese to work with the input core > =c) > > > > Rodrigo |
|
From: Rodrigo D. <cu...@uo...> - 2002-03-06 01:53:22
|
IEkgd291bGQgZ3Vlc3MgaGUgd2FudHMgaGVscCBnZXR0aW5nIGNoaW5lc2UgdG8gd29yayB3 aXRoIHRoZSBpbnB1dCBjb3JlID1jKQ0KDQpSb2RyaWdvDQoNCkh1IFlvbmcgd3JvdGU6DQoN Cj7HsMPmzNbC27W9emhjb261xMSjv+m7r87KzOKjrLK7udzEo7/p1+7W1cjnus67rrfWo6y0 08D6wLS6utfWz7XNs8novMa1xM+wud8NCj6/tKOs1sHJ2dKq09DX1szlus3K5Mjrt6jEo7/p o6y2+MfSy/zDx7a8vt+xuMDgy8a1xMzYteOjrLy0z+C21L3PtsDBoqOs17DU2C8NCj7KudPD vc/B6bvuo6zE2rTmz/u6xLTzo6y+zbmmxNzJz7b40dTKx2ZvbnQvaW5wdXS1xHNlcnZlcqGj y/nS1LHIvc/KyrrPtsDBotPaDQo+emhjb27AtNTL0NChow0KPtLUyrLDtNH5tcS3vcq91MvQ 0KOs1eLKx8/C0ruyvbHIvc+52NDEtcTOyszioaPO0sjPzqq7+bG+09DS1M/Cwb3W1re9yr2j rL/JuakNCj7RodTxo7oNCj4xoaJtb2R1bGUNCj4gICDSsr7Nysex4NLrs8kqLm+jrNPDaW5z bW9k17DU2KGjyr63trPM0PLI53VuaWNvbrXEZW5jb2RlLWdiLm+how0KPiAgIG1vZHVsZbbU tq/MrMTatOa1xLncwO3T0DEyOGu1xM/e1sajrNXi0rK+zcrHZW5jb2RlLWdizqrKssO00qqw 0dfWv+LIq7K/1/YNCj6zyWOzzNDyo6y2+LK7yse0q82ztcS2wc7EvP7XsNTYtcTUrdLyoaMN Cj4gICBtb2R1bGXTprjDv8nS1GV4cG9ydLP2z7XNs7X308OjrLmpxuTL/G1vZHVsZbvyvfiz zLX308Ohow0KPjKhomRhZW1vbg0KPiAgIMrYu6S9+LPMv8nE3Lj8ysrTw9Paz9bU2rXEemhj b26jrMDgy8a1xLPM0PLTprjDtuC/tL+0yNWxvsjLtcS2q873o6wNCj5GcmVlV25uus1DYW5u YaGjy/zDx7XEyuTI67eot9azyXNlcnZlcrrNY2xpZW50s8zQ8qOstrzS1GRhZW1vbrXEt73K vdTL0NCho9DpDQo+xOLW1bbLs8zQ8sjnamZidGVybaOsuLrU8NCttfe6zbncwO2how0KPiAg ILb4x9LL/MPH0rLWxraowcvX1Ly6tcS3x1i1xMrkyOu3qL3Tv9qho7i9tPjLtdK7vuSjrLj5 vt3O0rbUcGNm0dC+v7XEvq0NCj7R6aOs1Npjb25zb2xltcSzzNDy1tDWsb3TzNfTw1i1xGxp Yr/JxNzQ1LK7tPOjrMn11sHV1bDhuf3AtNKy09DOyszioaPS8s6qWLXEDQo+tqvO97a8u/nT 2tfUvLrSu8zXxr3MqKOsvLTKucrHuty88rWltcS2q8730rK2q8CtzvezttK7tPO20aOsutzE 0bD+wOuho7jfsuPQrQ0KPtLpsrvJ5rywtb2+38zls8zQ8qOstbnKx7/J0tTKx8q508Ohow0K Pg0KPs+jzfu087zStuC3orHt0uK8+6GjDQo+DQoNCg0K |
|
From: Hu Y. <ccp...@et...> - 2002-03-05 05:58:09
|
前面讨论到zhcon的模块化问题，不管模块最终如何划分，从历来汉字系统设计的习惯 看，至少要有字体和输入法模块，而且它们都具备类似的特点，即相对较独立，装载/ 使用较灵活，内存消耗大，就功能上而言是font/input的server。所以比较适合独立于 zhcon来运行。 以什么样的方式运行，这是下一步比较关心的问题。我认为基本有以下两种方式，可供 选择： 1、module 也就是编译成*.o，用insmod装载。示范程序如unicon的encode-gb.o。 module对动态内存的管理有128k的限制，这也就是encode-gb为什么要把字库全部做 成c程序，而不是传统的读文件装载的原因。 module应该可以export出系统调用，供其它module或进程调用。 2、daemon 守护进程可能更适用于现在的zhcon，类似的程序应该多看看日本人的东西， FreeWnn和Canna。它们的输入法分成server和client程序，都以daemon的方式运行。虚 拟终端程序如jfbterm，负责协调和管理。 而且它们也制定了自己的非X的输入法接口。附带说一句，根据我对pcf研究的经 验，在console的程序中直接套用X的lib可能性不大，甚至照搬过来也有问题。因为X的 东西都基于自己一套平台，即使是很简单的东西也东拉西扯一大堆，很难剥离。高层协 议不涉及到具体程序，倒是可以是使用。 希望大家多发表意见。 |
|
From: Hu Y. <ccp...@et...> - 2002-03-05 04:03:20
|
Error operation to bother you, just delete this and last my mail. Very sorry! |
|
From: Hu Y. <ccp...@et...> - 2002-03-05 03:59:33
|
7．系统调用
到此为止，我们做的事情就是使用定义好的内核机制来注册/proc文件和设备句柄。这
在做内核常规处理的事情时是很理想的。但是如果你希望做一些非常规的事情、改变系
统的
行为的时候该怎么办呢？这就必须依靠自己。
这就是内核编程变得危险的地方。在写下面的例子的时候，我关闭了open系统调用。
这意味着我不能打开任何文件，不能运行任何程序，而且不能关闭计算机。我必须拉住
电源
开关。幸运的是，没有文件丢失。为确保你也不会丢失任何文件，在做insmod以及
rmmod
前请执行sync权限，
忘记/proc文件，忘记设备文件。它们只是不重要的细节。真正的同内核通信的过程机
制是被所有进程公用的，这就是系统调用。当一个进程请求内核服务时（比如打开文
件、创
建一个新进程或者要求更多内存），就需要使用这个机制。如果你想用比较有趣的方法
改变
内核行为，这就是你所需要的。另外，如果你希望看到程序使用了哪一个系统调用，运
行
strace 。
一般的，进程是不能访问内核的。它不能访问内核所占内存空间也不能调用内核函数。
CPU硬件决定了这些（这就是为什么它被称作“保护模式”）。系统调用是这些规则的
一个
例外。其原理是进程先用适当的值填充寄存器，然后调用一个特殊的指令，这个指令会
跳到
一个事先定义的内核中的一个位置（当然，这个位置是用户进程可读但是不可写的）。
在Intel
CPU中，这个由中断0x80实现。硬件知道一旦你跳到这个位置，你就不是在限制模式下
运
行的用户，而是作为操作系统的内核――所以你就可以为所欲为。
进程可以跳转到的内核位置叫做sysem_call。这个过程检查系统调用号，这个号码告诉
内核进程请求哪种服务。然后，它查看系统调用表(sys_call_table)找到所调用的内核
函数入
口地址。接着，就调用函数，等返回后，做一些系统检查，最后返回到进程（或到其他
进程，
如果这个进程时间用尽）。如果你希望读这段代码，它在源文件目录
//kernel/entry.S，Entry(system_call)的下一行。
所以，如果我们希望改变某个系统调用的工作方式，我们需要写我们自己的函数（通
常是加一点我们自己的代码然后调用原来的函数）来实现，然后改变sys_call_table中
的指
针使其指向我们的函数。因为我们可能以后会删除，而且不希望系统处在不稳定状态，
所以
在cleanup_module中保存该表的原来状态很重要。
这里的源代码是一个这样的核心模块的例子。我们希望“窥探”一个用户，每当这个
用户打开一个文件是就printk一条消息。为达到这个目的，我们把打开文件的系统调用
替换
为我们自己的函数，our_sys_open。这个函数检查当前进程的uid（用户的id），如果
它等于
我们要窥探的uid，就调用printk来显示所打开文件的文件名。然后，可以用任何一种
方法，
用同样的参数调用原来的open函数，或者真正打开文件。
Init_module函数把sys_call_table中的适当地址上的内容替换，把原来的指针保存在
一
个变量里。Cleanup_module函数用这些变量恢复所有的东西。这种方法是危险的，因为
两
个内核模块可能改变了同一个系统调用。设想我们由两个内核模块，A和B。A的open系
统调用是A_open，B的open系统调用是B_open。现在，如果A插入内核，系统调用将被
替换为A_open，当完成以后调用sys_open。然后，B被插入内核，把系统调用替换为
B_open，
而完成的时候，它将会调用它认为原始的系统调用的A_open，。
那么，如果B被首先删除，不会出现任何错误――它只是把系统调用恢复成A_open，
A_open再去调用原始的的系统调用。然而，如果先删除A，再删除B，系统就会崩溃。A
的删除将会把系统调用恢复成sys_open，而把B切换出了循环。然后，当B被删除时，将
会把系统调用恢复成A_open，但是A_open已经不在内存。初看来，似乎我们可以通过检
查系统调用是否等于我们的open函数来解决这个问题，如果是就不要改变它（这样B被
删
除的时候就不会改变系统调用），但是这样会引起一个更加恶劣的问题。当A被删除
时，它
看到系统调用被改成了B_open而不再指向A_open，所以在它被删除时就不会恢复
sys_open。
不幸的是，B_open仍然试图恢复A_open，但它已不再内存，这样，即使没有删除B系统
也
会崩溃。
我可以提出两个方法来解决这个问题。第一个方法是把调用恢复成原始值，sys_open。
不幸的是sys_open不是在/proc/ksyms中的内核系统表中的一部分，所以我们不能访问
它。
另一个解决办法是使用索引计数器来阻止root 去rmmod这个模块，一旦它被装载。这在
生
产性模块中是好的，但是对教学里中不是很好――这就是为什么我不在这里这样做。
ex syscall.c
/* syscall.c
*
* System call \"stealing\" sample
*/
/* Copyright (C) 1998-99 by Ori Pomerantz */
/* The necessary header files */
/* Standard in kernel modules */
#include /* We\'re doing kernel work */
#include /* Specifically, a module */
/* Deal with CONFIG_MODVERSIONS */
#if CONFIG_MODVERSIONS==1
#define MODVERSIONS
#include
#endif
#include /* The list of system calls */
/* For the current (process) structure, we need
* this to know who the current user is. */
#include
/* In 2.2.3 /usr/include/linux/version.h includes a
* macro for this, but 2.0.35 doesn\'t - so I add it
* here if necessary. */
#ifndef KERNEL_VERSION
#define KERNEL_VERSION(a,b,c) ((a)*65536+(b)*256+(c))
#endif
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
#include
#endif
/* The system call table (a table of functions). We
* just define this as external, and the kernel will
* fill it up for us when we are insmod\'ed
*/
extern void *sys_call_table[];
/* UID we want to spy on - will be filled from the
* command line */
int uid;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
MODULE_PARM(uid, \"i\");
#endif
/* A pointer to the original system call. The reason
* we keep this, rather than call the original function
* (sys_open), is because somebody else might have
* replaced the system call before us. Note that this
* is not 100% safe, because if another module
* replaced sys_open before us, then when we\'re inserted
* we\'ll call the function in that module - and it
* might be removed before we are.
*
* Another reason for this is that we can\'t get sys_open.
* It\'s a static variable, so it is not exported. */
asmlinkage int (*original_call)(const char *, int, int);
/* For some reason, in 2.2.3 current->uid gave me
* zero, not the real user ID. I tried to find what went
* wrong, but I couldn\'t do it in a short time, and
* I\'m lazy - so I\'ll just use the system call to get the
* uid, the way a process would.
*
* For some reason, after I recompiled the kernel this
* problem went away.
*/
asmlinkage int (*getuid_call)();
/* The function we\'ll replace sys_open (the function
* called when you call the open system call) with. To
* find the exact prototype, with the number and type
* of arguments, we find the original function first
* (it\'s at fs/open.c).
*
* In theory, this means that we\'re tied to the
* current version of the kernel. In practice, the
* system calls almost never change (it would wreck havoc
* and require programs to be recompiled, since the system
* calls are the interface between the kernel and the
* processes).
*/
asmlinkage int our_sys_open(const char *filename,
int flags,
int mode)
{
int i = 0;
char ch;
/* Check if this is the user we\'re spying on */
if (uid == getuid_call()) {
/* getuid_call is the getuid system call,
* which gives the uid of the user who
* ran the process which called the system
* call we got */
/* Report the file, if relevant */
printk(\"Opened file by %d: \", uid);
do {
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
get_user(ch, filename+i);
#else
ch = get_user(filename+i);
#endif
i++;
printk(\"%c\", ch);
} while (ch != 0);
printk(\"\\n\");
}
/* Call the original sys_open - otherwise, we lose
* the ability to open files */
return original_call(filename, flags, mode);
}
/* Initialize the module - replace the system call */
int init_module()
{
/* Warning - too late for it now, but maybe for
* next time... */
printk(\"I\'m dangerous. I hope you did a \");
printk(\"sync before you insmod\'ed me.\\n\");
printk(\"My counterpart, cleanup_module(), is even\");
printk(\"more dangerous. If\\n\");
printk(\"you value your file system, it will \");
printk(\"be \\\"sync; rmmod\\\" \\n\");
printk(\"when you remove this module.\\n\");
/* Keep a pointer to the original function in
* original_call, and then replace the system call
* in the system call table with our_sys_open */
original_call = sys_call_table[__NR_open];
sys_call_table[__NR_open] = our_sys_open;
/* To get the address of the function for system
* call foo, go to sys_call_table[__NR_foo]. */
printk(\"Spying on UID:%d\\n\", uid);
/* Get the system call for getuid */
getuid_call = sys_call_table[__NR_getuid];
return 0;
}
/* Cleanup - unregister the appropriate file from /proc */
void cleanup_module()
{
/* Return the system call back to normal */
if (sys_call_table[__NR_open] != our_sys_open) {
printk(\"Somebody else also played with the \");
printk(\"open system call\\n\");
printk(\"The system may be left in \");
printk(\"an unstable state.\\n\");
}
sys_call_table[__NR_open] = original_call;
}
===================================================================
Hu Yong
Shanghai eCircle co.,Ltd.
Web: http://www.ecircle.com.cn/
Mail hu...@ec...
Tel: 86-21-54620864
FAX: 86-21-54210085
|
|
From: Ralf A. <ra...@KO...> - 2002-03-03 22:05:54
|
Hello,
(to start with - i'm usually not permanently following the mail in the
linuxconsole list, so this may sound obvious for you - but in another list
(wearable computers) it's not. so maybe here is a good place to ask).
i'm just collecting the available information for the following scenario -
so maybe that has been solved long before or somebody has valuable hints
on it (it actually sounds very simple):
- Starting point: a system running Linux (either in text mode or using X)
- Intended mode of operation:
* i'd like to use a text "terminal" (with a size = lines*columns that
can be dynamically chosen) - so operations like "cursor goes to the
beginning of next line of previous is full", scrolling ... work well
inherently - and applications don't have to care for it
* the ASCII context of the display is transmitted to an external
display (e.g. a monitor/HMD using the BOB-II serial=>NTSC/PAL
converter)
* the "external" device is rather "dumb" - basically it can display
ASCII characters at a postion you specify (it's not a full featured
VT100, i guess then it would be very simple)
* "refresh" operations are either synchronous (whenever something on
the original display changes) or asynchronous (the external display
driver "polls" the original "screen" and may still do some kind of
optimization on whether and which data has to actually be
transmitted).
If we worked with some kind of "memory mapped terminal" that would be very
simple - you just had to check a certain memory area for the information.
>From what i understand the whole thing also has been done when treating
the display data as "full graphics data" - that's what a graphics
framebuffer device does (and those are well supported by Linux)
=> a question to the MITthrill people - is it possible to access the
code you developed for driving the modified MicroOptical QVGA
displays (is it 320x240 color btw?) via a specialized framebuffer
driver?
Anyway - for the ASCII-text-only case - is this functionality already
present or can be implemented in a very simple way using "standard means"?
Any ideas are very welcome! Having kind of a "xterm" with user specified
size and the ASCII content of just that "xterm" (that can still "live" on
a primary screen) transmitted to an external viewing device would also be
great.
best regards
ralf
--
Best regards,
Ralf Ackermann
---------------------------------------------------------------
Hosting the IP Telephony Field Trial for the Darmstadt Region
---------------------------------------------------------------
Ralf Ackermann _ ra...@KO...
Industrial Process and |/ | | |\/| Merckstrasse 25
System Communications |\ |_| | | 64283 Darmstadt, Germany
Tel.: (+49) 6151 16-6138 Fax: (+49) 6151 16-6152
---------------------------------------------------------------
http://www.kom.e-technik.tu-darmstadt.de/~rac
---------------------------------------------------------------
|
|
From: Johann D. <de...@if...> - 2002-03-03 19:47:12
|
Alexander Rawass wrote: > Hi, > > some critical feedback about your homepage: > > http://linuxconsole.sourceforge.net/ > > You should move this page _below_ this page: > http://linuxconsole.sourceforge.net/input/input.html > Why ? The top page describes the linuxconsole project. The input part is a piece of the linuxconsole project, not the contrary. > Or at least give your central index page the same outfit and links as the > other pages. > I guess appearance is not the main concern here. Most of people are busy maintaining/debugging drivers. Especially now, there is a lot of stuff going on with the new 2.5 kernel series. > When you have a look (as a user) at > http://linuxconsole.sourceforge.net/ > > You'll see only a small homepage without much docu or anything about it. > > There's just this tiny link 'Input API' - and that leads you to the rest of > the homepage (which looks rather nice). > > It's very easy to miss that 'Input API' link - I would think it leads to some > sort of javadoc/doxygen generated docu, but I wouldn't image that it leads to > the real homepage? Here again, you missed the fact that linuxconsole is not only about input. There is also the console part, which is important as well. > > So, the index page should have the same nice styling and the links from the > other pages, that would be a lot better , easier to use and find :-) > You are right, the communication could be improved. James did a lot of work previously on the web page, but I guess none of us actually wants to spend too much (any?) time on the appearance of the pages. -- Johann Deneux ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif |
|
From: Johann D. <de...@if...> - 2002-03-03 11:48:43
|
Alexander Rawass wrote: > Hi, > > I am a Co-Developer to Vegastrike vegastrike.sourceforge.net, a 3D space > fight sim. > > I have written the joystick support for Vegastrike, and now I own a new > force-feedback joystick, so I'll do also the Force Feedback support for > Vegastrike. > > I've already got contacts to Johann Deneux, but I'm now also on the > libff-devel and linuxconsole-dev mailing lists. > > My job would be, to help write a high-level force feedback library, and then > make Vegastrike use it. > > What has been done in writing such a high-level library already? > Any concepts yet etc? > We have been discussing the API. A first draft is ready, and we should start to implement it any time soon. Rodrigo, could you commit the header to CVS ? > Currently, I've installed kernel-2.4.12 and using Johanns patch for this > kernel. > > I've read through the docu, and got my system to recognize the joystick. > > I've got an AVB Top Shot Pegasus (connected to the serial port): > > [alex@jungle vegastrike-current]$ jstest /dev/js0 > Joystick (ttyS1/serio0/input0) has 6 axes and 13 buttons. Driver version is > 2.1.0. > Testing ... (interrupt to exit) > Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 Buttons: > 0:off 1:off 2:off 3:off 4:off 5:on 6:off 7:off 8:off 9Axes: 0: > 0 1: 0 2: 0 3: 0 4: 0 5: 0 Buttons: 0:off 1:off > 2:off 3:off 4:off 5:on 6:off 7:off 8:off 9 > > Some questions: > > the right 'eight way' hatswitch is recognized as axes 4&5 - why is that > hatswitch an axis - and not maybe a row of buttons? Hats really are axes, aren't they ? I mean, if you see them as buttons, that means the left and the right positions could be enabled at the same time, which isn't the case. But you're right to rise the question, the left hatswitch should be seen as axes as well, which isn't the case for the moment. > > The Button Nr.2 and Button Nr.3 (in terms of my joysticks manual) are somehow > 'swapped' - at least, 'Button 2' is button nr. 2 in jstest, and 'Button 3' is > button 1 in jstest. I have a tendancy to ignore these docs (they don't say anything about the protocol used ;) I will fix it. > > The eventtest util also works fine for me: > [alex@jungle ff-utils]$ ./evtest /dev/input/event0 > Input driver version is 1.0.0 > Input device ID: bus 0x3 vendor 0x5ef product 0x20a version 0x0 > Input device name: "ttyS1/serio0/input0" > Supported events: > > [etc] > > > ffset -a <whatever> > > seems also to work fine - the autocenter gets set from 0 to 100. > > > What doesn't work is fftest: This is a more annoying issue. > > [alex@jungle ff-utils]$ ./fftest /dev/input/event0 > Force feedback test program. > HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES > > Device /dev/input/event0 opened > Axes query: Axis X Axis Y > Effects: Constant Periodic Spring Friction > Number of simultaneous effects: 20 > Enter effect number, -1 to exit > 1 > Enter effect number, -1 to exit > 2 > > Nothing happens at all. What about effects 0 and 3 ? Do they work ? Did you try to change the magnitude of effects ? Did you try with USB ? > > How can I use the other ff-utils (no docu?)? ffcfstress stresses the joystick by simulating a spring using only constant force effects (as explained in the source). ffmvforce generates forces directed toward the mouse pointer. It's also a kind of stress test. I don't see what kind of documentation you expect ? The only meaningful utilities are those to set the gain and the auto-center. Others are code sample, and the documentation is naturally situated inside the code. > > Do I have to switch the joystick on at boot time to get it recognized by the > driver? > No, you don't. Of course, you need to have it switched on when you load the driver and start inputattach. But that needn't be at boot time. > What has stopped working is my old-analogue joystick: > > [root@jungle /root]# modprobe ns558 > /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: init_module: No > such device > Hint: insmod errors can be caused by incorrect module parameters, including > invalid IO or IRQ parameters > /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod > /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o failed > /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod ns558 failed > > Before I used 2.4.12, I tried using 2.4.2 with it's non-force-feedback > 'iforce' drivers. > > With 2.4.2, my analogue joystick became js0 and the Pegasus was js1. > > Now, with 2.4.12, the loading of ns558 doesn't work anymore - I dunno why? > Me neither. Perhaps a problem with es1371 ??? But I don't think the I-Force driver has anything to do with that (especially as ns558 is loaded before the iforce stuff). My patch does not touch ns558, btw. > I don't think that's a problem with the force-feedback-drivers - any idea why > it doesn't want my ns558 module (haven't changed anything in BIOS or > interrupts). > > See here my loading script: > > echo "Loading Sound modules" > > modprobe es1371 joystick=0x200 > > echo "Loading Joystick modules" > > modprobe joydev # userland interface > modprobe ns558 # gameport driver > modprobe analog # analog-joystick > > modprobe serio > modprobe serport > modprobe iforce > modprobe evdev > > /usr/local/bin/inputattach --iforce /dev/ttyS1 & > > > Any ideas or comments? > > I'll hope I'll be able to update on 2.4.17 soon. > > > > Alex > > -- Johann Deneux ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif |
|
From: Alexander R. <ale...@us...> - 2002-03-02 23:29:19
|
Hi, some critical feedback about your homepage: http://linuxconsole.sourceforge.net/ You should move this page _below_ this page: http://linuxconsole.sourceforge.net/input/input.html Or at least give your central index page the same outfit and links as the other pages. When you have a look (as a user) at http://linuxconsole.sourceforge.net/ You'll see only a small homepage without much docu or anything about it. There's just this tiny link 'Input API' - and that leads you to the rest of the homepage (which looks rather nice). It's very easy to miss that 'Input API' link - I would think it leads to some sort of javadoc/doxygen generated docu, but I wouldn't image that it leads to the real homepage? So, the index page should have the same nice styling and the links from the other pages, that would be a lot better , easier to use and find :-) Alex -- Alexander Rawass Email: ale...@us... http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net ...but some day you'll be a STAR in somebody else's SKY... |
|
From: Alexander R. <ale...@us...> - 2002-03-02 23:29:16
|
Hi, I am a Co-Developer to Vegastrike vegastrike.sourceforge.net, a 3D space fight sim. I have written the joystick support for Vegastrike, and now I own a new force-feedback joystick, so I'll do also the Force Feedback support for Vegastrike. I've already got contacts to Johann Deneux, but I'm now also on the libff-devel and linuxconsole-dev mailing lists. My job would be, to help write a high-level force feedback library, and then make Vegastrike use it. What has been done in writing such a high-level library already? Any concepts yet etc? Currently, I've installed kernel-2.4.12 and using Johanns patch for this kernel. I've read through the docu, and got my system to recognize the joystick. I've got an AVB Top Shot Pegasus (connected to the serial port): [alex@jungle vegastrike-current]$ jstest /dev/js0 Joystick (ttyS1/serio0/input0) has 6 axes and 13 buttons. Driver version is 2.1.0. Testing ... (interrupt to exit) Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:on 6:off 7:off 8:off 9Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:on 6:off 7:off 8:off 9 Some questions: the right 'eight way' hatswitch is recognized as axes 4&5 - why is that hatswitch an axis - and not maybe a row of buttons? The Button Nr.2 and Button Nr.3 (in terms of my joysticks manual) are somehow 'swapped' - at least, 'Button 2' is button nr. 2 in jstest, and 'Button 3' is button 1 in jstest. The eventtest util also works fine for me: [alex@jungle ff-utils]$ ./evtest /dev/input/event0 Input driver version is 1.0.0 Input device ID: bus 0x3 vendor 0x5ef product 0x20a version 0x0 Input device name: "ttyS1/serio0/input0" Supported events: [etc] ffset -a <whatever> seems also to work fine - the autocenter gets set from 0 to 100. What doesn't work is fftest: [alex@jungle ff-utils]$ ./fftest /dev/input/event0 Force feedback test program. HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES Device /dev/input/event0 opened Axes query: Axis X Axis Y Effects: Constant Periodic Spring Friction Number of simultaneous effects: 20 Enter effect number, -1 to exit 1 Enter effect number, -1 to exit 2 Nothing happens at all. How can I use the other ff-utils (no docu?)? Do I have to switch the joystick on at boot time to get it recognized by the driver? What has stopped working is my old-analogue joystick: [root@jungle /root]# modprobe ns558 /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: init_module: No such device Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o failed /lib/modules/2.4.12/kernel/drivers/char/joystick/ns558.o: insmod ns558 failed Before I used 2.4.12, I tried using 2.4.2 with it's non-force-feedback 'iforce' drivers. With 2.4.2, my analogue joystick became js0 and the Pegasus was js1. Now, with 2.4.12, the loading of ns558 doesn't work anymore - I dunno why? I don't think that's a problem with the force-feedback-drivers - any idea why it doesn't want my ns558 module (haven't changed anything in BIOS or interrupts). See here my loading script: echo "Loading Sound modules" modprobe es1371 joystick=0x200 echo "Loading Joystick modules" modprobe joydev # userland interface modprobe ns558 # gameport driver modprobe analog # analog-joystick modprobe serio modprobe serport modprobe iforce modprobe evdev /usr/local/bin/inputattach --iforce /dev/ttyS1 & Any ideas or comments? I'll hope I'll be able to update on 2.4.17 soon. Alex -- Alexander Rawass Email: ale...@us... http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net ...but some day you'll be a STAR in somebody else's SKY... |
|
From: Johann D. <de...@if...> - 2002-03-01 18:25:55
|
Christian Helmuth wrote: > Hi folks, > > I'm working (again) with code from ruby and try to find out how it works. My > intention is to use drivers/input as a basis for "libinput" in our > microkernel environment. > > As I gathered the input architecture looks like this: > > +-------+ > | evdev | > +-------+ > | > +-------+ > | input | > +-------+ > | > +-------+ > +--------------| serio |--------------+ > | +-------+ | > | | > +--------------+ +--------------+ > | PORT | logically connected | DEVICE | > | e.g. i8042.c |<=====================>| e.g. atkbd.c | > +--------------+ +--------------+ > > > Is that right? And where is the connection point for USB? Is it the same > layer as serio right below input? USB and serio are used by device drivers to communicate with the device. The input component knows nothing about it. So yes, USB plays a role similar to serio, but no, it's not connected to input. Instead, it's the device driver that registers itself to input. -- Johann Deneux ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif |
|
From: James S. <jsi...@tr...> - 2002-02-28 18:53:49
|
> James and Vojteh, You should agree serial mouse support. After > Vojteh's > suggestion I use drivers/input/serio/serport_old.o. > May be I should manualy remove drivers/char/serial.o from > drivers/char/Makefile > and then use new serial_8250? No need to. The idea is that the serial layer will eventually have a core that is independent of the tty layer. Then we will have a input api interface layer on top of that. > drivers\input\touchscreen\Config.in stop "make menuconfig" with error. .. You must have a old snapshot? > diff -r ruby/linux/drivers/serial/serial_8250.c > linux/drivers/serial/serial_8250.c > 1784c1784 > < return MKDEV(TTY_MAJOR, 64 + co->index); > --- > > return mk_kdev(TTY_MAJOR, 64 + co->index); > 1843c1843 Oh. That stuff is old. I have to update it. |
|
From: <tr...@jo...> - 2002-02-28 16:22:47
|
Hi,
In utils/scancodes.h there are two XT scancodes used by Korean keyboard(0x71 and 0x72). I want to make these keys supported also for AT keyboard because that is the widely used in Korea at this time.
Korean AT keyboard has two keys named Hangul/English and Hanja and the scancodes are 0xf2 and 0xf1. These scancodes are produced on key press and nothing on key release.
This is a problem for current input system which expects event on either up or down. So simply adding these scancodes to the translation table in atkbd.c wasn't sufficient. By emulating key up/down in i8052.c I could solve the problem.
This patch does the work. If you see no problem I hope it to be committed.
By the way, how is the keycode translated by keyboard.c?
- emulate_raw() have to recover real scancode from keycode. Am I right?
- But medium raw mode seems to generate incompatible codes with OLD(2.4) keycodes.
- There is no range check for keycode used for indexing key_map which still havs 128 entries.
Without clearing these matters, I can't go further.
Thanks,
TR Lim
Patch follows
Index: linux/drivers/input/keyboard/atkbd.c
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/linux/drivers/input/keyboard/atkbd.c,v
retrieving revision 1.33
diff -u -r1.33 atkbd.c
--- linux/drivers/input/keyboard/atkbd.c 12 Feb 2002 09:34:34 -0000 1.33
+++ linux/drivers/input/keyboard/atkbd.c 28 Feb 2002 14:55:38 -0000
@@ -60,7 +60,7 @@
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
252,253, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 254, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,255,
+ 254,191,190, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,255,
0, 0, 92, 90, 85, 0,137, 0, 0, 0, 0, 91, 89,144,115, 0,
136,100,255, 0, 97,149,164, 0,156, 0, 0,140,115, 0, 0,125,
0,150, 0,154,152,163,151,126,112,166, 0,140, 0,147, 0,127,
Index: linux/drivers/input/serio/i8042.c
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/linux/drivers/input/serio/i8042.c,v
retrieving revision 1.19
diff -u -r1.19 i8042.c
--- linux/drivers/input/serio/i8042.c 15 Feb 2002 00:25:24 -0000 1.19
+++ linux/drivers/input/serio/i8042.c 28 Feb 2002 14:55:38 -0000
@@ -399,6 +399,11 @@
}
}
i8042_kbd_port.dev->interrupt(&i8042_kbd_port, data, 0);
+ /* Emulate up/down for Korean keyboard. */
+ if (data == 0xf1 || data == 0xf2) {
+ i8042_kbd_port.dev->interrupt(&i8042_kbd_port, 0xf0, 0);
+ i8042_kbd_port.dev->interrupt(&i8042_kbd_port, data, 0);
+ }
}
}
}
Index: utils/scancodes.h
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/utils/scancodes.h,v
retrieving revision 1.7
diff -u -r1.7 scancodes.h
--- utils/scancodes.h 25 Sep 2001 09:37:57 -0000 1.7
+++ utils/scancodes.h 28 Feb 2002 14:55:38 -0000
@@ -494,8 +494,8 @@
* USB language switching keys (see USB HID Usage Tables)
*/
- { 0x071, 0, 0, 0, 0x90, 0x68, 0, 0, 0, 0, 190 }, /* Language1 Korean Hangul/English */
- { 0x072, 0, 0, 0, 0x91, 0x66, 0, 0, 0, 0, 191 }, /* Language2 Korean Hanja */
+ { 0x072, 0x0f2, 0, 0, 0x90, 0x68, 0, 0, 0, 0, 190 }, /* Language1 Korean Hangul/English */
+ { 0x071, 0x0f1, 0, 0, 0x91, 0x66, 0, 0, 0, 0, 191 }, /* Language2 Korean Hanja */
{ 0, 0, 0, 0, 0x92, 0, 0, 0, 0, 0, 192 }, /* Language3 */
{ 0, 0, 0, 0, 0x93, 0, 0, 0, 0, 0, 193 }, /* Language4 */
{ 0, 0, 0, 0, 0x94, 0, 0, 0, 0, 0, 194 }, /* Language5 */
|
|
From: Christian H. <ch...@os...> - 2002-02-28 11:12:53
|
Hi folks,
I'm working (again) with code from ruby and try to find out how it works. My
intention is to use drivers/input as a basis for "libinput" in our
microkernel environment.
As I gathered the input architecture looks like this:
+-------+
| evdev |
+-------+
|
+-------+
| input |
+-------+
|
+-------+
+--------------| serio |--------------+
| +-------+ |
| |
+--------------+ +--------------+
| PORT | logically connected | DEVICE |
| e.g. i8042.c |<=====================>| e.g. atkbd.c |
+--------------+ +--------------+
Is that right? And where is the connection point for USB? Is it the same
layer as serio right below input?
As I understand PS/2 mice are handled by i8042.c, but they are an extra PORT
for a mouse DEVICE, right?
Maybe I'm entirely wrong .. plz help me.
w/ regards
--
Christian Helmuth
## Dept. of Computer Science, Dresden University of Technology, Germany ##
## email: ch...@os... http://wwwos.inf.tu-dresden.de/~ch12 ##
## PGP fingerprint: A3 CD 20 89 1C 69 AC C7 46 B1 FA 19 89 3C 39 C6 ##
|
|
From: Johann D. <de...@if...> - 2002-02-27 22:30:43
|
Johann Deneux wrote:
> Hi,
>
> I am having some trouble with 2.5.5-dj1 + the hid from CVS.
> hid_init_reports
> sends two control URBs. Those are the messages from the kernel: usb.c:
> registered new driver hid hid-core.c: HID probe called for ifnum 0 "
> submitting ctrl urb " ctrl urb status ok (added by myself, in
> the completion handler if urb->status == 0) " undefined
> report_id 0 received " submitting ctrl urb " ctrl urb
> status -32 received (-32 -> -EPIPE, stall) usb_control/bulk_msg:
> timeout usb-ohci.c: unlink URB timeout
>
> I commented out the call to hid_dump_device, as it hindered me from
> reading
> the beginning of the log.
>
> At this point, my box freezes :(
>
> Handling stalls when dealing with non-control URBs seems easy, but
> in this case, I'm lost...
>
> Ah, last detail: the device works fine with linux 2.4.17 (which
> includes an old version of hid)
>
As I suspected a bug in USB, I tried to import hid*.{c,h} from the
current CVS into kernel 2.4.17. The same freeze occured.
I think I found the reason: the completion handlers may submit the next
report if any, and then directly returns, without releasing the spinlock
(and without restoring the irq flags). If I add a call to
spin_unlock_irq_restore there, my kernel no longer freezes, but I get an
oops instead.
I commited the fix, as well as modifications to usb_alloc_urb and
usb_submit_urb (missing second parameter).
--
Johann Deneux
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
|
|
From: Aivils S. <Aiv...@un...> - 2002-02-27 07:12:20
|
Hi
James and Vojteh, You should agree serial mouse support. After
Vojteh's
suggestion I use drivers/input/serio/serport_old.o.
May be I should manualy remove drivers/char/serial.o from
drivers/char/Makefile
and then use new serial_8250?
drivers\input\touchscreen\Config.in stop "make menuconfig" with error.
This one allow me run 2.5.2-ruby:
diff -r ruby/linux/Makefile linux/Makefile
183a184,185
> DRIVERS-$(CONFIG_GAMEPORT) += drivers/input/gameport/gamedrv.o
> DRIVERS-$(CONFIG_SERIO) += drivers/input/serio/seriodrv.o
diff -r ruby/linux/drivers/Makefile linux/drivers/Makefile
29a30,31
> subdir-$(CONFIG_GAMEPORT) += input/gameport
> subdir-$(CONFIG_SERIO) += input/serio
diff -r ruby/linux/drivers/input/Config.in linux/drivers/input/Config.in
10,22d9
< comment 'Userland interfaces'
< dep_tristate ' Keyboard interface' CONFIG_INPUT_KEYBDEV $CONFIG_INPUT
< dep_tristate ' Mouse interface' CONFIG_INPUT_MOUSEDEV $CONFIG_INPUT
< dep_mbool ' Provide legacy /dev/psaux device'
CONFIG_INPUT_MOUSEDEV_PSAUX $CONFIG_INPUT
< if [ "$CONFIG_INPUT_MOUSEDEV" != "n" ]; then
< int ' Horizontal screen resolution' CONFIG_INPUT_MOUSEDEV_SCREEN_X
1024
< int ' Vertical screen resolution' CONFIG_INPUT_MOUSEDEV_SCREEN_Y 768
< fi
< dep_tristate ' Joystick interface' CONFIG_INPUT_JOYDEV $CONFIG_INPUT
< dep_tristate ' Touchscreen interface' CONFIG_INPUT_TSDEV $CONFIG_INPUT
< dep_tristate ' Event interface' CONFIG_INPUT_EVDEV $CONFIG_INPUT
< dep_tristate ' Event debugging' CONFIG_INPUT_EVBUG $CONFIG_INPUT
<
32c19
< source drivers/input/touchscreen/Config.in
---
> # source drivers/input/touchscreen/Config.in
diff -r ruby/linux/drivers/input/serio/Config.in
linux/drivers/input/serio/Config.in
13c13
< dep_tristate ' Serial port line discipline' CONFIG_SERIO_SERPORT
$CONFIG_SERIO
---
> dep_tristate ' Serial port line discipline' CONFIG_SERIO_SERPORT_OLD
$CONFIG_SERIO
diff -r ruby/linux/drivers/input/serio/Makefile
linux/drivers/input/serio/Makefile
18a19
> obj-$(CONFIG_INPUT_SERPORT_OLD) += serport_old.o serio.o
diff -r ruby/linux/drivers/serial/serial_8250.c
linux/drivers/serial/serial_8250.c
1784c1784
< return MKDEV(TTY_MAJOR, 64 + co->index);
---
> return mk_kdev(TTY_MAJOR, 64 + co->index);
1843c1843
< wait_key: serial8250_console_wait_key,
---
> //wait_key: serial8250_console_wait_key,
diff -r ruby/linux/drivers/serial/serial_core.c
linux/drivers/serial/serial_core.c
1409c1409
< int retval, line = MINOR(tty->device) - tty->driver.minor_start;
---
> int retval, line = minor(tty->device) - tty->driver.minor_start;
diff -r ruby/linux/drivers/video/vgacon.c linux/drivers/video/vgacon.c
489a490
> vc->display_fg = vt;
Aivils Stoss
|
|
From: Rodrigo D. <cu...@uo...> - 2002-02-27 01:08:38
|
Hi people...I wonder if the question about the FF API was=3D20
settled, and if it's already working for PID devices(I'll get the CVS=3D2=
0
tree and test it anyway). I also have some news - there are two labs in=3D=
20
my university which are asking me to work on this driver - one of=3D20
them(the one I work in) has a CAVE where they need force feedback=3D20
working in their linux cluster(since it's very unlikely it can be easily=3D=
20
done on their Onyx 3200), and the robotics lab has a project which will=3D=
20
use PID devices too.
Also, as you probably know, I have started libff, which is going=3D=
20
slow, but will come out eventually...any and all help is appreciated.
Rodrigo
--=20
*******************************
* Rodrigo Damazio *
* *************************** *
* cu...@uo... *
* rod...@po... *
* ICQ: #3560450 *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=C3=A7=C3=A3o *
* Escola Polit=C3=A9cnica *
* USP - S=C3=A3o Paulo *
*******************************
|
|
From: Johann D. <de...@if...> - 2002-02-26 23:43:44
|
Hi,
I am having some trouble with 2.5.5-dj1 + the hid from CVS.
hid_init_reports sends two control URBs. Those are the messages from the
kernel:
usb.c: registered new driver hid
hid-core.c: HID probe called for ifnum 0
" submitting ctrl urb
" ctrl urb status ok (added by myself, in the completion
handler if urb->status == 0)
" undefined report_id 0 received
" submitting ctrl urb
" ctrl urb status -32 received (-32 -> -EPIPE, stall)
usb_control/bulk_msg: timeout
usb-ohci.c: unlink URB timeout
I commented out the call to hid_dump_device, as it hindered me from
reading the beginning of the log.
At this point, my box freezes :(
Handling stalls when dealing with non-control URBs seems easy, but in
this case, I'm lost...
Ah, last detail: the device works fine with linux 2.4.17 (which includes
an old version of hid)
--
Johann Deneux
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
|
|
From: Johann D. <de...@if...> - 2002-02-25 20:13:12
|
Oliver Hamann wrote: > Vojtech Pavlik wrote: > >>On Sat, Feb 23, 2002 at 11:40:51PM +0100, Johann Deneux wrote: >> >>>Hi, >>> >>>Today I bought two Logitech devices: the wingman force 3d and the >>>cordless rumblepad. >>> >>>Good news: after a few hours hacking, I think I managed to figure out >>>most of the protocol used by thess devices. I haven't yet written any >>>piece of code, so it's far from finished, but I am enthusiastic about my >>>findings. >>> >>>These two devices share the same principle: The cpu of the PC does most >>>of the work. Thus periodic effects are simulated using constant effects, >>>not unlike ffcfstress works. The joystick does have special packets for >>>springs, though. >>> >>>The rumble pad has two unmatched motors. That is, they are different. >>>The left one seems to be able to produce large low-freq oscillations, >>>the right one generates hi-freq small vibrations. Better, I noticed a >>>packet my first attempt with alexander failed to reveal. >>> >>>I hope I can get some piece of code to run this week end. >>> >>Good work! Congratulations! >> > > Fine, maybe I should not sell my WingMan Force 3D... :o) Maybe not. It feels quite nice. Light, and you can hardly feel the gears inside. A bit weak, though. > > I think, possibly most devices will be simplified in the future. Do you > think it is necessary to have a simulating layer for all the effects in > the kernel? Or should it be solved in a high level API? That's a good question. I have been thinking about it this week end. As several applications may access the device, it is maybe a good idea to put the emulation code inside the kernel, because it knows about all processes. On the other hand, this emulation may need arithmetics, and kernel modules cannot use the fpu. For example, I need the cos and sin functions, because the API specifies angles+magnitude, while the protocol uses X and Y magnitudes. I haven't yet been able to find out whether fixed-point versions of these functions exist in the kernel. Implementing it using tables should not be too hard, especially as we don't need a very high precision. A resolution of 1° should be enough, and that means storing 45 values, which sounds reasonable. If we leave the emulation in userland, a fear we may end up having many games using only constant force effects (why bother using other time-based effects if you need to do the emulation for some devices anyway ?) However, doing the stuff in the kernel means we need some kind of thread+timer or interrupt to update the device at regular intervals. If we do it cleverly, we can perhaps adjust the interrupt frequency to minimize the load. Anyway, the first step consists in simply getting the things shake. I fear some init packets I missed may be necessary, and finding init packets is not especially an easy nor delightful task. -- Johann Deneux ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif |
|
From: svetljo <ga...@st...> - 2002-02-25 16:50:16
|
> > >Hi > May be You can run two XFree servers with new James's vt-manager. >You should configure VGA console Framebuffer console and Virtual >framebuffer under ruby. >If two keyboards is plugged in, one is binnded with VGA and second is >binded with Virtual fb. > I really would like to do it that way, but ... 2.5.5-dj1 (form the 2.5.x )is the first kernel that i could boot on my system and ruby is still up to 2.5.2 i can not simply copy it over my tree and i'm not sure that matrox G550DH and SiS 6356 are ported to ruby > >So >/dev/tty1 - /dev/tty15 work with first keyboard >/dev/tty16 - /dev/tty32 work with second keyboard > >You should run 1-st X server : >$startx -- :0 -xf86config 1-stXF86Config vt07 > >2-nd server: >$startx -- :1 -xf86config 2-ndXF86Config vt17 > > >1-st server grab vt07 binded with 1-st keyboard. >2-nd server grab vt17 binded with 2-nd keyboard. > > >Current, in my end, I could choose XFree keyboard with simple vtxx command, >but my nvidia TNT2 (AGP) and 3DFX Voodoo3 (PCI) will not run simultaneous 2 >X servers. I hope solve this with right X configuration. I use X 4.1.0 >without any patch, because ruby vt-manager allow bind several keyboards >with sevral /dev/tty's. > / We have been trying to get several xervers running at the same time. We have applied the patches to disable the VT handling + home grown ones to handle keyboard and mouse events, but there is still something funny going on: For each server server started, the previous ones will stop their output. stopping the servers in the reverse order will also enable the previous server again! After some late nights and much head scratching we found what we consider a severe misfeature: when X starts up it will scan the PCI bus for all cards, collecting all video cards and promplty call DisablePciAccess for each card, even tough the card is not mentioned in the config file, this will disable all output to for anny previously started servers, it does not look like the previous xserver is aware of this, it continues running, no error messages, and if we start a test program it will continue running. Stopping the last server wil "reenable" the previous one as if nothing had happened. We have come up with the following hack: in *xc/programs/Xserver/hw/xfree86/common/xf86Config.c* in the configDevice function we record the busid of the card from the config file in a global var and in */xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c* in the *FindPCIVideoInfo* whe jump over the initalizations if the card does not match the one in our global, this seems to work for now. We are now able to start several servers without interference Now this is of course a monumental kludge, so could somone who has a good grasp of the inards and secrets of the PCI stuff please lend us a hand ? We think it should work is as follows: Dont touch cards not mentioned in the config file period. :-) Kim "kill" Lilliestiena http://www.itr.no/~kill RHCE/RHCEX: www.redhat.com/rhce/rhce806199965400509.html // /that maybe can help you http://village.flashnet.it/users/fn048069/multiuser.html ----------------------------------------------------------------------------------------------------------------------------------------------------------- / /Date: Wed, 27 Jun 2001 15:56:01 -0700 (PDT) From: Mark Vojkovich To: Kim Lilliestierna cc: xpert mailing list Subject: Re: [Xpert]Problems with multi x servers On Thu, 28 Jun 2001, Kim Lilliestierna wrote: > We think it should work is as follows: > > Dont touch cards not mentioned in the config file period. :-) > You have to. If they are both vga cards and the X-server is trying to run the one that isn't the primary head, you have to disable I/O access to the primary card and enable for the secondary card instead. VGA cards share resources. The only reason why you get graphics at all after you boot up with multiple cards is because the bios disabled all but one of them. A single server can run multiple VGA cards similtaneously because it mediates access to them, putting them on and pulling them off of the bus when appropriate. I believe the XFree86 RAC code only does this pulling and putting when necessary (ie, only when there are resource conflicts). / / / / ------------------------------------------------------------------------ / / |
|
From: Oliver H. <au...@od...> - 2002-02-25 13:39:50
|
Vojtech Pavlik wrote: > > On Sat, Feb 23, 2002 at 11:40:51PM +0100, Johann Deneux wrote: > > Hi, > > > > Today I bought two Logitech devices: the wingman force 3d and the > > cordless rumblepad. > > > > Good news: after a few hours hacking, I think I managed to figure out > > most of the protocol used by thess devices. I haven't yet written any > > piece of code, so it's far from finished, but I am enthusiastic about my > > findings. > > > > These two devices share the same principle: The cpu of the PC does most > > of the work. Thus periodic effects are simulated using constant effects, > > not unlike ffcfstress works. The joystick does have special packets for > > springs, though. > > > > The rumble pad has two unmatched motors. That is, they are different. > > The left one seems to be able to produce large low-freq oscillations, > > the right one generates hi-freq small vibrations. Better, I noticed a > > packet my first attempt with alexander failed to reveal. > > > > I hope I can get some piece of code to run this week end. > > Good work! Congratulations! Fine, maybe I should not sell my WingMan Force 3D... :o) I think, possibly most devices will be simplified in the future. Do you think it is necessary to have a simulating layer for all the effects in the kernel? Or should it be solved in a high level API? Oliver Hamann |
1998 messages has been excluded from this view by a project administrator.
