Re: copter-commander
Christoph Egger wrote: Well, I never could get /dev/input/event0 to work, Haven't you forgotten to a) make sure, that you have loaded the event driver (if compiled as a module) or that you have it compiled as builtin kernel driver? b) make sure, the permissions of /dev/input/event0 are correct? c) make use of the libgii's linux-evdev target? Will input-linux-evdev work with no USB devices plugged into the system? Does the evdev kernel module have an undeclared dependancy on some usb module? Common description of evdev: The input-linux-evdev target handles all events, that comes from the linux event device file. So, if input-linux-evdev works, when no USB devices plugged in, depends if the event device file works without them. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] Sent through GMX FreeMail - http://www.gmx.net " Description: Binary data
GGIMesa
Hello everyone! I have posted a first version of my GGIMesa patch at http://www.student.math.uwaterloo.ca/~fspacek/ggimesa.diff It is mostly functional, but there are still some (mostly implementation) details that need to be worked out, so I didn't post it to Mesa3D ml, but rather I seek advice here. I have tested the patch on 8 and 16 bit single and double buffered X target as well as the aalib target. I currently have no other targets to test it on (though KGI is very very very close) so if anybody wants to give it a shot somewhere else I'd be grateful. I've radicaly changed the interface. It follows the ideas I've outlined in my previous mail (since nobody seemed to have any serious objections). First of all, I've attempted to follow the usual extension use patterns more closely. The functions ggiMesaInit and ggiMesaAttach are now mandatary and GGIMesa will _not_ take care of them silently if you forget them. The new interface is as follows: int ggiMesaExtendVisual(ggi_visual_t vis, GLboolean alpha_flag, GLboolean stereo_flag, GLint depth_size, GLint stencil_size, GLint accum_red_size, GLint accum_green_size, GLint accum_blue_size, GLint accum_alpha_size, GLint num_samples); This is probably the first call one should make. It will extend visual by certain capabilities that cannot be specified by ggi_mode. Note however that everything that can be specified by the visual's mode is. That means RGB/COLOR_INDEX as well as single/double buffering is set up depending on the current mode. Note that call to this function is not strictly necessary. As the name suggests, it merely extends the visual. So if the capabilities that can be provided by the ggi-only visual are sufficient you don't need to call this. ggi_mesa_context_t ggiMesaCreateContext(ggi_visual_t vis); Create a context capable of being used to render on visual vis. This is a fundamental one, and one would usually call it after the visual is properly extended. void ggiMesaMakeCurrent(ggi_mesa_context_t ctx, ggi_visual_t vis); Bind the context to the visual and select the context as the current one. Now for the issues: I would very much like to make Mesa use as transparent as possible. What that means is that once the user extends the visual, it should be possible to ggiSetMode and GGIMesa would adapt. Currently (using the GGI_CHG_APILIST) it is capable of resizing the necessary buffers (there is a bug in the code and it crashes after about a 20 resizes). However I am not at all sure about what to do about change of graphtype. Obviously there will be a lot of state that will no longer be valid in a different graphtype. Currently I'm thinking of complely invalidating contexts bound to the visual but that violates my ideal of making the use totally transparent. If anybody has a better idea please help me out. What I'm trying to do is make up an interface that would be useable even later when a windowing system uses ggi and wants to do Mesa with direct rendering. What I'm envisioning is some sort of flow-through visual for the window in question (I know Stefan has done something similar for Berlin). For this to work, it must be possible to resize the visual without disturbing the context. I have not submitted this patch to Mesa3d yet, and I will not do so until the above issues are resolved. Since most of the problems are GGI and not Mesa related, I figured I'd post this here now. -Filip
Re: GGIMesa
On Fri, 14 Dec 2001, Filip Spacek wrote: Hello everyone! I have posted a first version of my GGIMesa patch at http://www.student.math.uwaterloo.ca/~fspacek/ggimesa.diff Wow! 64K is an amazing size... (If it would only be compressed 64K... ;-)) And your gear-on-AAlib screenshot looks very cool, too. Great work! It is mostly functional, but there are still some (mostly implementation) details that need to be worked out, so I didn't post it to Mesa3D ml, but rather I seek advice here. I have tested the patch on 8 and 16 bit single and double buffered X target as well as the aalib target. I currently have no other targets to test it on (though KGI is very very very close) so if anybody wants to give it a shot somewhere else I'd be grateful. I've radicaly changed the interface. It follows the ideas I've outlined in my previous mail (since nobody seemed to have any serious objections). First of all, I've attempted to follow the usual extension use patterns more closely. The functions ggiMesaInit and ggiMesaAttach are now mandatary and GGIMesa will _not_ take care of them silently if you forget them. The new interface is as follows: int ggiMesaExtendVisual(ggi_visual_t vis, GLboolean alpha_flag, GLboolean stereo_flag, GLint depth_size, GLint stencil_size, GLint accum_red_size, GLint accum_green_size, GLint accum_blue_size, GLint accum_alpha_size, GLint num_samples); This is probably the first call one should make. It will extend visual by certain capabilities that cannot be specified by ggi_mode. Note however that everything that can be specified by the visual's mode is. That means RGB/COLOR_INDEX as well as single/double buffering is set up depending on the current mode. Note that call to this function is not strictly necessary. As the name suggests, it merely extends the visual. So if the capabilities that can be provided by the ggi-only visual are sufficient you don't need to call this. ggi_mesa_context_t ggiMesaCreateContext(ggi_visual_t vis); Create a context capable of being used to render on visual vis. This is a fundamental one, and one would usually call it after the visual is properly extended. void ggiMesaMakeCurrent(ggi_mesa_context_t ctx, ggi_visual_t vis); Bind the context to the visual and select the context as the current one. Now for the issues: I would very much like to make Mesa use as transparent as possible. What that means is that once the user extends the visual, it should be possible to ggiSetMode and GGIMesa would adapt. Currently (using the GGI_CHG_APILIST) it is capable of resizing the necessary buffers (there is a bug in the code and it crashes after about a 20 resizes). Do you make use of libbuf for buffer support? If yes, you might found a bug in libgalloc (libgalloc is responsible for resizing of resources). However I am not at all sure about what to do about change of graphtype. You have to overload libggi's internal getapi function. The libxmi's X/Xlib targets gives you an idea how to do that. But be careful: you must call libggi's getapi function, too. Otherwise LibGGI wouldn't handle the reloading of its own default sublibs anymore. Obviously there will be a lot of state that will no longer be valid in a different graphtype. Currently I'm thinking of complely invalidating contexts bound to the visual but that violates my ideal of making the use totally transparent. If anybody has a better idea please help me out. What I'm trying to do is make up an interface that would be useable even later when a windowing system uses ggi and wants to do Mesa with direct rendering. What I'm envisioning is some sort of flow-through visual for the window in question (I know Stefan has done something similar for Berlin). For this to work, it must be possible to resize the visual without disturbing the context. Sounds good. I have not submitted this patch to Mesa3d yet, and I will not do so until the above issues are resolved. Since most of the problems are GGI and not Mesa related, I figured I'd post this here now. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
