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: Romain D. <do...@ir...> - 2001-09-27 09:31:33
|
Romain Dolbeau wrote: > Still, I guess I should use them ; I think I could add > a 'number of FOURCC supported' field in the > "struct fb_vidoverlay_avail", and add (yet) another > ioctl to get only the variable-length FOURCC list. F-up myself, here's an updated file. The sample implementation in pm3fb compile (not near thebox, can't test it yet :-) Any comment/criticism/improvement/advice very much welcome. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Romain D. <do...@ir...> - 2001-09-27 08:01:39
|
Nick Kurshev wrote: > As I've found - mplayer knows much more video image formats: > > file main/libvo2/img_format.h Yes, FOURCC code. You're not the first one to mention them... The problem is, there's a bunch of them (see <http://www.webartz.com/fourcc/>, for those who don't know them), and advertising them isn't easy... Still, I guess I should use them ; I think I could add a 'number of FOURCC supported' field in the "struct fb_vidoverlay_avail", and add (yet) another ioctl to get only the variable-length FOURCC list. BTW, what do the linux-console folks think of adding video overlay support to Ruby ? -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Nick K. <nic...@ma...> - 2001-09-27 06:05:21
|
Hello, Romain! On Wed, 26 Sep 2001 10:51:04 +0200, you wrote: > Nick Kurshev wrote: > > > 1. What about adding video extensions to devfb? > > Well, it would need a standard way of querying the video > capability of the chip and using it. Not easy... > I've written a draft proposal for that, amd implemented > it in pm3fb (my fb driver for the permedia3), but it still > needs discussion. If there's interest in it, the likely > target would be kernel 2.5.x in Ruby (the new framebuffer > layer, see <http://sourceforge.net/projects/linuxconsole/> > > Appended is the preliminary include file. > > Any comment/criticism/improvement/advice very much welcome. > > -- > DOLBEAU Romain | l'histoire est entierement vraie, puisque > ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre > do...@ir... | -- Boris Vian As I've found - mplayer knows much more video image formats: file main/libvo2/img_format.h /* RGB/BGR Formats */ #define IMGFMT_RGB_MASK 0xFFFFFF00 #define IMGFMT_RGB (('R'<<24)|('G'<<16)|('B'<<8)) #define IMGFMT_RGB8 (IMGFMT_RGB|8) #define IMGFMT_RGB15 (IMGFMT_RGB|15) #define IMGFMT_RGB16 (IMGFMT_RGB|16) #define IMGFMT_RGB24 (IMGFMT_RGB|24) #define IMGFMT_RGB32 (IMGFMT_RGB|32) #define IMGFMT_BGR_MASK 0xFFFFFF00 #define IMGFMT_BGR (('B'<<24)|('G'<<16)|('R'<<8)) #define IMGFMT_BGR8 (IMGFMT_BGR|8) #define IMGFMT_BGR15 (IMGFMT_BGR|15) #define IMGFMT_BGR16 (IMGFMT_BGR|16) #define IMGFMT_BGR24 (IMGFMT_BGR|24) #define IMGFMT_BGR32 (IMGFMT_BGR|32) /* Planar YUV Formats */ #define IMGFMT_YVU9 0x39555659 #define IMGFMT_IF09 0x39304649 #define IMGFMT_YV12 0x32315659 #define IMGFMT_I420 0x30323449 #define IMGFMT_IYUV 0x56555949 #define IMGFMT_CLPL 0x4C504C43 /* Packed YUV Formats */ #define IMGFMT_IYU1 0x31555949 #define IMGFMT_IYU2 0x32555949 #define IMGFMT_UYVY 0x59565955 #define IMGFMT_UYNV 0x564E5955 #define IMGFMT_cyuv 0x76757963 #define IMGFMT_YUY2 0x32595559 #define IMGFMT_YUNV 0x564E5559 #define IMGFMT_YVYU 0x55595659 #define IMGFMT_Y41P 0x50313459 #define IMGFMT_Y211 0x31313259 #define IMGFMT_Y41T 0x54313459 #define IMGFMT_Y42T 0x54323459 #define IMGFMT_V422 0x32323456 #define IMGFMT_V655 0x35353656 #define IMGFMT_CLJR 0x524A4C43 #define IMGFMT_YUVP 0x50565559 #define IMGFMT_UYVP 0x50565955 Other things look - ok. Best regards! Nick |
|
From: Romain D. <do...@ir...> - 2001-09-26 08:51:17
|
Nick Kurshev wrote: > 1. What about adding video extensions to devfb? Well, it would need a standard way of querying the video capability of the chip and using it. Not easy... I've written a draft proposal for that, amd implemented it in pm3fb (my fb driver for the permedia3), but it still needs discussion. If there's interest in it, the likely target would be kernel 2.5.x in Ruby (the new framebuffer layer, see <http://sourceforge.net/projects/linuxconsole/> Appended is the preliminary include file. Any comment/criticism/improvement/advice very much welcome. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven <lu...@dp...> - 2001-09-17 15:30:52
|
On Sat, Sep 15, 2001 at 07:40:52PM -0700, James Simmons wrote: > > > Ok, i was surprised because the passage to 2.4.8 for ruby was done well after > > the 2.4.9 release, but i suppose you import the kernel patch into the ruby > > tree gradually ? > > Well the reason I did this was I was doing ARM ruby developement. > Unfortunely Russell King moved over to the AC tree so I continued to do > developement on the ARM branch against Linus tree until just recently. > > > And i will also be able to use a second keyboard and mouse and have a second > > independent console, isn't it ? I will gladly test anything like that, and see > > how X needs to be modified accordyingly ? Right now it blanks all the heads of > > the same board, when running ... > > Yes. I believe using the -vt flag would allow X to run on two seperate > consoles at the same time. As for blanking well that is more of a problem. > Unfortunely you can't run a X server across multiple desktops at the same > time. As soon as it works, i will be testing it< As for X, even when you run two X servers (one as :1.0 on the first head, the other on :0.0 omn the second head, it will blank the not current head. bnut then maybe the fact that i had only one mouse and keybord to test it my be the xcause of it. Friendlym Sven Luther |
|
From: James S. <jsi...@tr...> - 2001-09-16 02:41:13
|
> Ok, i was surprised because the passage to 2.4.8 for ruby was done well after > the 2.4.9 release, but i suppose you import the kernel patch into the ruby > tree gradually ? Well the reason I did this was I was doing ARM ruby developement. Unfortunely Russell King moved over to the AC tree so I continued to do developement on the ARM branch against Linus tree until just recently. > And i will also be able to use a second keyboard and mouse and have a second > independent console, isn't it ? I will gladly test anything like that, and see > how X needs to be modified accordyingly ? Right now it blanks all the heads of > the same board, when running ... Yes. I believe using the -vt flag would allow X to run on two seperate consoles at the same time. As for blanking well that is more of a problem. Unfortunely you can't run a X server across multiple desktops at the same time. |
|
From: Sven <lu...@dp...> - 2001-09-15 06:17:34
|
On Fri, Sep 14, 2001 at 09:05:51AM -0700, James Simmons wrote: > > > > Huh ? the current ruby is against 2.4.8, and I fixed the only typos > > > that prevented it to build... > > > > Arg, ... surely that's why, why not against 2.4.9 ? > > I haven't ported it yet to 2.4.9. I plan to this weekend. Ok, i was surprised because the passage to 2.4.8 for ruby was done well after the 2.4.9 release, but i suppose you import the kernel patch into the ruby tree gradually ? > > BTW, will ruby fix dual head (i guess so) and the vga garbage stuff, or do i > > still need to go after it ? > > It should. And i will also be able to use a second keyboard and mouse and have a second independent console, isn't it ? I will gladly test anything like that, and see how X needs to be modified accordyingly ? Right now it blanks all the heads of the same board, when running ... Friendly, Sven Luther |
|
From: James S. <jsi...@tr...> - 2001-09-14 16:47:00
|
> > I wrote buggy code :-) I was copying a default cmap > > to unallocated space... now it (properly I hope) > > allocate the cmap which by default is the default cmap... A note about initalizing a video card. The fb console system does this for you. You don't need to set the video mode or the color map. A small note. You need the framebuffer console enable to do this. If you have a stand alone fbdev system you at present have to set the video mode with some userland application like fbset. I do plan to add a patch that sets the mode in register_framebuffer if the var.activate field is FB_ACTIVATE_NOW. This makes sense for embedded devices. |
|
From: James S. <jsi...@tr...> - 2001-09-14 16:06:12
|
> > Huh ? the current ruby is against 2.4.8, and I fixed the only typos > > that prevented it to build... > > Arg, ... surely that's why, why not against 2.4.9 ? I haven't ported it yet to 2.4.9. I plan to this weekend. > BTW, will ruby fix dual head (i guess so) and the vga garbage stuff, or do i > still need to go after it ? It should. |
|
From: Sven <lu...@dp...> - 2001-09-14 10:30:55
|
On Fri, Sep 14, 2001 at 11:54:12AM +0200, Romain Dolbeau wrote:
> Sven wrote:
>
> > BTW, could you send me diffs, or maybe have the pm3fb.c file available as a
> > standalone, yesterday's ruby died at build time in ksym.c.
>
> Huh ? the current ruby is against 2.4.8, and I fixed the only typos
> that prevented it to build...
>
> > Also, i am really curious of what happens on your box when you try it out ?
> > Apparently you don't even come that far ?
>
> It crash to xmon very early, with pm3fb or with offb (I should
> try again offb maybe it's better now...)
Nope, it still is a problem with cmap ...
the culprit code is :
cmap = &(l_fb_info->current_par->f_fb_info->cmap);
> the cmap takes an 9x130 value here
cmap->red = cmap->green = cmap->blue = cmap->transp = NULL;
> well the kernel oops with unable to handle kernel NULL pointer
dereference at virtual address 144 here
cmap->len = 0; cmap->start = 0;
fb_alloc_cmap(cmap, 16, 0);
So, i don't know, but i guess the cmap is not of the right type, or maybe you
should let the & away, or more simply the
l_fb_info->current_par->f_fb_info->cmap value is NULL. I guess it is this last
one that is the case, i did not test it though ...
Friendly,
Sven Luther
|
|
From: Sven <lu...@dp...> - 2001-09-14 09:58:09
|
On Fri, Sep 14, 2001 at 11:54:12AM +0200, Romain Dolbeau wrote: > Sven wrote: > > > BTW, could you send me diffs, or maybe have the pm3fb.c file available as a > > standalone, yesterday's ruby died at build time in ksym.c. > > Huh ? the current ruby is against 2.4.8, and I fixed the only typos > that prevented it to build... Arg, ... surely that's why, why not against 2.4.9 ? BTW, did you fix also the debugging stuff in pm3fb, so i could enable the master_debug variable ? In the meantime i just copied the more recent pm3fb files to my working 2.4.7+older ruby tree. > > Also, i am really curious of what happens on your box when you try it out ? > > Apparently you don't even come that far ? > > It crash to xmon very early, with pm3fb or with offb (I should > try again offb maybe it's better now...) what is xmon ? let's hope we will fix this nextly, BTW, will ruby fix dual head (i guess so) and the vga garbage stuff, or do i still need to go after it ? Friendly, Sven Luther > > -- > DOLBEAU Romain | l'histoire est entierement vraie, puisque > ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre > do...@ir... | -- Boris Vian |
|
From: Romain D. <do...@ir...> - 2001-09-14 09:54:18
|
Sven wrote: > BTW, could you send me diffs, or maybe have the pm3fb.c file available as a > standalone, yesterday's ruby died at build time in ksym.c. Huh ? the current ruby is against 2.4.8, and I fixed the only typos that prevented it to build... > Also, i am really curious of what happens on your box when you try it out ? > Apparently you don't even come that far ? It crash to xmon very early, with pm3fb or with offb (I should try again offb maybe it's better now...) -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven <lu...@dp...> - 2001-09-14 09:51:14
|
On Fri, Sep 14, 2001 at 11:20:54AM +0200, Romain Dolbeau wrote: > Sven Luther wrote: > > On Thu, Sep 13, 2001 at 10:53:31AM +0200, Romain Dolbeau wrote: > > > It shouldn't have been a copy but an alloc. I think :-) > > > > ??? > > I wrote buggy code :-) I was copying a default cmap > to unallocated space... now it (properly I hope) > allocate the cmap which by default is the default cmap... mmm, i tested it, it is now dying at c01e7ee3, the relevant portion of the System.map file is : c01e7de8 t pm3fb_common_init c01e7fd8 t pm3fb_decode_var so it is in pm3fb_common_init, i am just building a kernel with debug messages (printk's, not your debug stuff) enabled to know more about it. BTW, could you send me diffs, or maybe have the pm3fb.c file available as a standalone, yesterday's ruby died at build time in ksym.c. Also, i am really curious of what happens on your box when you try it out ? Apparently you don't even come that far ? Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-09-14 09:21:02
|
Sven Luther wrote: > On Thu, Sep 13, 2001 at 10:53:31AM +0200, Romain Dolbeau wrote: > > It shouldn't have been a copy but an alloc. I think :-) > > ??? I wrote buggy code :-) I was copying a default cmap to unallocated space... now it (properly I hope) allocate the cmap which by default is the default cmap... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven L. <lu...@la...> - 2001-09-14 05:21:34
|
On Thu, Sep 13, 2001 at 10:53:31AM +0200, Romain Dolbeau wrote: > Sven Luther wrote: > > > Ok, i will try it, what about the second bug ? the one about fb_cmap_copy ? > > It shouldn't have been a copy but an alloc. I think :-) ??? > It's in the latest CVS. Ok, will try it, the previous correction did solve the problem, but it still hanged at cmap copy as before. Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-09-13 08:53:38
|
Sven Luther wrote: > Ok, i will try it, what about the second bug ? the one about fb_cmap_copy ? It shouldn't have been a copy but an alloc. I think :-) It's in the latest CVS. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven L. <lu...@la...> - 2001-09-13 05:51:36
|
On Tue, Sep 11, 2001 at 02:18:08PM +0200, Romain Dolbeau wrote: > Romain Dolbeau wrote: > > > Yes, this come from a conceptual bug ; > > > > I'll fix that ASAP > > it was 'easier' than I thought. It's commited and _should_ > fix that problem... Ok, i will try it, what about the second bug ? the one about fb_cmap_copy ? Friendly, Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-09-11 12:18:13
|
Romain Dolbeau wrote: > Yes, this come from a conceptual bug ; > > I'll fix that ASAP it was 'easier' than I thought. It's commited and _should_ fix that problem... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Romain D. <do...@ir...> - 2001-09-11 11:59:33
|
Sven Luther wrote: > 1) the bug number one seem to be because some of the __fb_try_mode call are > done with a NULL info->fbops pointer. I don't understand why that is so, but > anyway naturally it will hang when trying to acceess > info->fbops->fb_check_var. Yes, this come from a conceptual bug ; I shouldn't have take the easy way and ported the old pm3fb. The old one used an integrated database of mode that didn't require all the data required by modedb. Of course I forgot to check that, and now, if you put a 'mode:' option, hell break loose. <sigh> I'll fix that ASAP ; in the meantime, you might want to try without any 'mode:' option, that _should_ bypass the bug and use 640x480@60... Thanks for the report, -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Sven L. <lu...@la...> - 2001-09-11 11:40:00
|
On Wed, Sep 05, 2001 at 05:51:53PM +0200, Romain Dolbeau wrote: > James Simmons wrote: > > > That sounds like a bug in the check_var function. When I get the chance I > > will go threw the code. > > Dunno if it was the bug, but my ugly code had an ugly bug that > needed an ugly fix (commited). if set_par was ever called prior > to that check_var, then it was the bug (the pointer > to the hardware-specific state got erased and never restored...) More checking gave the following : 1) the bug number one seem to be because some of the __fb_try_mode call are done with a NULL info->fbops pointer. I don't understand why that is so, but anyway naturally it will hang when trying to acceess info->fbops->fb_check_var. When returning 0 when info->fpops is null, i managed to get a bit further, but could not see more than the last lines of the debug because of the oops. Is there a way to access the log in this case, apart from a serial console, which i don't have ? On amiga, it was possible to get access to a log saved in memory with the amigaOS version of the dmesg program, i suppose this is not possible on i386,at least not with lilo/grub ? mmm, maybe grub can look at the memory at some location, and i can read it there. Anyway, i returned 0, and it followed a bit, but again hang as follows : kernel_thread init pm3fb_open pm3fb_detect pm3fb_common_init fb_copy_cmap. -> here it hangs in the first line, where we access tyo->start and from-> start to calculate tooff, to and from don't seem to be NULL though, which seems strange to me because nothing more happens there, but then maybe i botched soem of the printks i used. Also, Romain, when enabling MASTER_DEBUG=3, i had to do some file editing, because there were various problems which hindered the compilation, but the last message i got where : pm3fb_realsetup : setting mode for board #0. (but i think this was still without the workaround to bug #1, don't remember exactly). Hope this helps somewhat, please keep me informed on further evolution, and i will hapilly test them. BTW, is it possible to build a modular fb stuff + pm3fb, so as to shorten build and test time, and maybe get more informative log messages, or will this not work/not show the right info ? Friendly, Sven Luther |
|
From: James S. <jsi...@tr...> - 2001-09-10 16:22:20
|
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.8-ruby/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer > -fno-strict-aliasing -fno-common -D__powerpc__ -fsigned-char > -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring > -c -o hid-core.o hid-core.c > hid-core.c: In function `usb_hid_configure': > hid-core.c:1219: parse error before `}' > hid-core.c:1223: warning: implicit declaration of function `snprintf' > make[3]: *** [hid-core.o] Error 1 > ##### > > the snprintf is commented out, so the '}' directly > follow the 'if' (which is invalid). > > Dunno if I must remove the 'if' or uncomment the > snprintf... Ug!! My stupid mistake. Will fix. Try it now. |
|
From: Alex D. <ag...@ya...> - 2001-09-10 15:46:08
|
I tried to use usb snoopy with my ifeel mouse, however, when I install usb snoopy with my mouse, the mouse refuses to work. As soon as I unistall usb snoopy on the device, it starts working again. I'm not sure why. If I have time later this week I may look into it again. Any Ideas? Thanks, Alex __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Romain D. <do...@ir...> - 2001-09-10 08:50:40
|
##### gcc -D__KERNEL__ -I/usr/src/linux-2.4.8-ruby/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -c -o hid-core.o hid-core.c hid-core.c: In function `usb_hid_configure': hid-core.c:1219: parse error before `}' hid-core.c:1223: warning: implicit declaration of function `snprintf' make[3]: *** [hid-core.o] Error 1 ##### the snprintf is commented out, so the '}' directly follow the 'if' (which is invalid). Dunno if I must remove the 'if' or uncomment the snprintf... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Johann D. <jo...@Do...> - 2001-09-05 20:31:02
|
On Wed, 5 Sep 2001, Alex Deucher wrote: > Ok, I just read the forcefeedback documentation a > little better. I can download immersion studio when I > get home and take a look at what gets sent to my ifeel > mouse. However the mouse is USB. Does rs232spy > (formerly comportspy ?) support USB, or do I need > something else for that? No, you need a tool like Usb Snoopy: http://www.jps.net/~koma/ rs232 only deals with rs232. -- Johann Deneux http://www.esil.univ-mrs.fr/~jdeneux/projects/ |
|
From: Alex D. <ag...@ya...> - 2001-09-05 19:30:10
|
Ok, I just read the forcefeedback documentation a little better. I can download immersion studio when I get home and take a look at what gets sent to my ifeel mouse. However the mouse is USB. Does rs232spy (formerly comportspy ?) support USB, or do I need something else for that? Alex --- Johann Deneux <jo...@Do...> wrote: > On Wed, 5 Sep 2001, Alex Deucher wrote: > > > I am starting to look into the linuxconsole > > project, and I noticed that there was support for > > force feedback joysticks using the immersion > > technologies stuff. I have a logitech ifeel mouse > > that has a similar sort of thing, that is > apparently > > also from immersion corp. Do you know if they use > the > > same protocol off hand? would there be any chance > > that the "feel" features of the mouse might be > > supported by the new input drivers at some point? > > I have no idea what protocol ifeel mice use, and the > driver for force > feedback joysticks is designed for, well, joysticks > (and wheels), not > mice. Sorry. Adding support for mice would be nice: > window managers > already implement some kind of "resistance" when you > move windows above > others, and this effect, among others, would be nice > to render > IMO. Anybody with an ifeel mouse willing to have a > look at the protocol > used ? > > -- > Johann Deneux > http://www.esil.univ-mrs.fr/~jdeneux/projects/ > __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
1998 messages has been excluded from this view by a project administrator.
