Re: Fwd: 69030 driver
Rishabh Kumar Goel writes: Hi! Thanks for your suggestion. I tried that but nothing worked out. i am working on NetBSD. So i mapped the memory from 0xA to 0xB. From this memory mapped I tried to read a single byte from the device and also the word but of no use. I get only 0xFF. My first aim is to get the Green Light(LED) on the monitor to glow. How to get that thing. To explain to you every step that's required to make this happen would exceed the what I can provide to you here considering my limited time. There is a fully functional driver for this chipset in XFree86. Why don't you have a look there? It performs every step required to make happen what you want. We also have code to talk to the VGA memory aperture. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Touchscreen input driver
Bodo Bimboese wrote: Hello All, Please apologize if this request is wrongly placed. I'm not familiar with programming, just a keen user. I'd be thankful, if anybody could point me into the right direction. I'm using X (4.3.0) on Linux, and I'm struggling to get a touchscreen (-input) device to work. It's not one of those popular manufacturers whose driver is included with 4.3.0 Things I've found out yet: manufacturer of the 12 TFT monitor with touchscreen is a no-name Asia-based. The interface is RS-232 with 9-pin serial connector and a PS/2 dongle-style plug (the mouse plugs into the back of this plug). Touchpanel manufacturer is a company called Hantouch Serial driver PCB manufacturer is a company called Sena (both companies offer downloads, but I didn't found any for X) The monitor is marketed under the label Glancetron in Europe (They only offer Win drivers unfortunately) Since I haven't found any *nix drivers on the net, I've tested all input drivers which came with X. None of the touchscreen drivers work, some cause X to abort. The only reaction I get is from the DigitalEdge tablet driver, which causes a 'click' in the bottom right corner of the screen, no matter on which area I touch it. My question is: Would it be an easy task to modify an existing driver to get the touch element to work? I've had a look at the Elotouch driver sources, and it doesn't look huge. I have no idea about programming, but I'm motivated to take the challenge. Sure, but you need to know what the incoming packets look like. Have you dropped a line to Hantouch? If you have, and they're unwilling to help, you probably can track RS-232 communications between the touchscreen and the Windows driver... Good luck! -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Fwd: Re: Fwd: Vblank support in kernel and X server]
On Thu, 2003-09-11 at 16:55, Alan Cox wrote: On Mer, 2003-09-10 at 23:21, Michel Dnzer wrote: On Wed, 2003-09-10 at 19:00, Jim Gettys wrote: Here's Alan Cox's mail about it. In 2.4.20-ac1. Won't this conflict with the DRM vblank interrupt handling? (I've also seen framebuffer device patches for this...) Thats a matter for the X server driver modules. If DRM provides it then don't ask for it from the vblank code. In the case of framebuffer the same can be said. Nothing prevents one app from using the DRM interface, another the framebuffer device and yet another the generic vblank one, and at most one of them will work as expected in that case. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: setjmp needs fixing again, here's the issues
On Wed, Sep 10, 2003 at 02:17:50PM -0700, John Meacham wrote: On Wed, Sep 10, 2003 at 03:37:57PM -0400, John Dennis wrote: 1) It may be hard to know the alignment requirements for all OS's and architectures (thats part of the reason we have system header files). We could guess 16 byte is sufficient. But even if we got the alignment requirement right how do we specify the alignment requirement to the compiler in a portable way such that it will build on a variety of systems and compilers? My understanding is that compiler alignment directives are not portable (e.g. not part of ANSI C). Are we comfortable picking one or two common alignment directives and conditionally compiling with the right one? Since we already have a jmp_buf which is much larger than necisarry, all that is needed is to take the first offset into it which is properly aligned for the given architecture and use that as the system jmp_buf. when the compiler can guarentee the proper alignment this becomes a 'nop', otherwise we waste at most alignment - sizeof(intmax_t) - 1 bytes. not a big deal. best of all, this can be implemented portably quite easily. The attached patch is one way this could be done. I've set the alignment higher than it probably needs to be. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com Index: loader/xf86sym.c === RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/loader/xf86sym.c,v retrieving revision 1.235 diff -u -r1.235 xf86sym.c --- loader/xf86sym.c24 Aug 2003 19:58:05 - 1.235 +++ loader/xf86sym.c12 Sep 2003 15:07:52 - @@ -907,6 +907,7 @@ SYMFUNC(xf86setjmp1) #endif SYMFUNCALIAS(xf86longjmp,longjmp) + SYMFUNCALIAS(xf86longjmp0,longjmp) SYMFUNC(xf86getjmptype) SYMFUNC(xf86setjmp1_arg2) SYMFUNC(xf86setjmperror) Index: os-support/xf86_ansic.h === RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/os-support/xf86_ansic.h,v retrieving revision 3.51 diff -u -r3.51 xf86_ansic.h --- os-support/xf86_ansic.h 24 Aug 2003 17:37:03 - 3.51 +++ os-support/xf86_ansic.h 12 Sep 2003 15:15:36 - @@ -312,10 +312,19 @@ extern int xf86setjmperror(xf86jmp_buf env); extern int xf86getjmptype(void); extern void xf86longjmp(xf86jmp_buf env, int val); +extern void xf86longjmp0(xf86jmp_buf env, int val); + +#define jb_align(env) \ + ((int *)(unsigned long)(env)) + JMP_BUF_ALIGN - 1) / \ + JMP_BUF_ALIGN) * JMP_BUF_ALIGN)) + #define xf86setjmp_macro(env) \ - (xf86getjmptype() == 0 ? xf86setjmp0((env)) : \ - (xf86getjmptype() == 1 ? xf86setjmp1((env), xf86setjmp1_arg2()) : \ - xf86setjmperror((env + (xf86getjmptype() == 0 ? xf86setjmp0(jb_align(env)) : \ + (xf86getjmptype() == 1 ? xf86setjmp1(jb_align(env), xf86setjmp1_arg2()) : \ + xf86setjmperror(jb_align(env + +#define xf86longjmp_macro(env, val) \ + xf86longjmp(jb_align(env), val) #else /* XFree86LOADER || NEED_XF86_PROTOTYPES */ #include unistd.h Index: os-support/xf86_libc.h === RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/os-support/xf86_libc.h,v retrieving revision 3.57 diff -u -r3.57 xf86_libc.h --- os-support/xf86_libc.h 24 Aug 2003 17:37:03 - 3.57 +++ os-support/xf86_libc.h 12 Sep 2003 15:19:33 - @@ -95,7 +95,9 @@ typedef int xf86key_t; /* setjmp/longjmp */ -typedef int xf86jmp_buf[1024]; +#define JMP_BUF_SIZE 4096 +#define JMP_BUF_ALIGN 4096 +typedef int xf86jmp_buf[(JMP_BUF_SIZE + JMP_BUF_ALIGN) / sizeof(int)]; /* for setvbuf */ #define XF86_IONBF1 @@ -688,7 +690,7 @@ #undef setjmp #define setjmp(a) xf86setjmp_macro(a) #undef longjmp -#define longjmp(a,b)xf86longjmp(a,b) +#define longjmp(a,b)xf86longjmp_macro(a,b) #undef jmp_buf #define jmp_buf xf86jmp_buf #endif
