Re: the GGI-over-/dev/fb blues
Do the mouse events work in the GGI applications (the monitest uses the mouse in the Flatpanel test for example) ? no, they don't. O.K. - the mouse is incorrectly cofigured somewhere. Presumably in the svgalib config files that are as well read by LibGGI. I tried Jon's suggestion and set the GGI_FBDEV_OPTIONS to -novt. No. That will not help. It effectively disables Linux-specific support for some inputs. This screwed things up even more, i.e. now the application doesn't react to events at all and I get a terminal writing over the application... Yes. This is the expected behaviour. This is done in $(prefix)/etc/ggi/input/linux-mouse, as documented in lib/libgii/doc/inputs.txt . hmm. The file linux-mouse didn't even exist. Yes. This is on purpose, as it normally autodetects, if no file is given. I created it and tried a couple of different devices. XF86Config contains the protocol 'PS/2', the mouse is a LogiTech. O.K. - if it is a PS/2 mouse, it should work with the ps/2 driver. So I tried both, ps2 and mmanps2 (as suggested by the docs). My linux-mouse file now contains one line: mmanps2 Still no success. Um - you read the docs to the end, did you ? It expects -- snip mouse ps2 mdev /dev/psaux -- snip to be in the file. The latter entry can probably be pointed to /dev/mouse, given a proper symlink. Also, I tried to install the kgi module, without success. The virtual consoles (beside the one running X) become essentially unreadable. Though the graphic card was correctly detected. What card ? Maybe this is an unstable driver. the configure tool reports: 'ATI Mach64 GT (Rage II) found. Using VGA driver' That means, that the card can be detected, but only the VGA driver is available for it, which is pretty much useless for something like Berlin. Try using either the kernel-provided ATI-fb driver (it doesn't state explicitly, though, if the Rage II is supported), or the kernel-provided VESA driver. If that doesn't work, you can still resort to XFree-DGA in order to get a fullscreen-demo for Berlin. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: GGI support for non standard FB devices
OK well I have started modifying GGI/fbdev to support my YUV framebuffer and its turning out to be fairly straight forward, However the sole purpose for porting GGI is to get XGGI running on our platform. If I understand you correctly then XGGI contains specific fb rendering code that does not just use the underlying GGI graphics lib functions??? Yes. This is due to the structure of the X-consortium server that was used as a base. It will acquire a directbuffer and render to it. If this is the case then what is involved in doing mods to XGGI such that it would work on our YUV framebuffer??? IIRC there are subdirectories for each renderer. You'd have to copy one of them, link it into the building process and modify it to understand the framebuffer arch you have. I am keen to get something running quickly so if I started off by using a fb translation method what would be the best way of doing it? (ie: is fbdev the best target to use, what is the best way to trigger translation frames?) As a "quick-hack", I'd say that writing something like a "dbemu" target would be best. The idea would be to make a cross between the memory target and one of the *emu targets. This target would open a truecolor memory-buffer and intercept ggiFlush on it. When ggiFlush gets called, it would scan the framebuffer for changed lines and blit those out using the child target's native functions. Another idea would be a shm-coupled system that works like the cube3d. You write a small native LibGGI Program that reads from a shared-memory located memory target and writes to your framebuffer and then you redirect XGGI to the same shared memory area. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: more questions, was: direct buffers, flushing
Hi again!
Is 8 bytes right, not 8 bits?
Umm - I see my notation is unclear. I'll better put it in words:
You divide pixelformat-size, which is in bits, by eight, what gives you the
step size in bytes.
Yea, yea I know what you mean.
Unless you have 8 BPP (yes, S3 cards do have a linear 4-bit mode), that
should always result in a whole integer.
No, I haven't
If I'm at the last pixel of a row, the jump should be only the size of one
pixel, or pixelPointer++ to get to the first pixel of the next row.
Yes, but only, if there is no padding. The graphics hardware may (for whatever
reason) decide to set a frame with a larger xvirtual and even that might not
correspond to the framebuffer layout, as there might be extra padding
areas that may not be used in each line. IIRC the MediaGX chipset does this
to gain alignment advantages and use less bandwidth by having precalculated
"compressed" lines in the extra space.
But
pixelPointer += stride - mode.virt.x;
should work for all cards?
That's strange. However there was a SEGV problem with ggiClose for quite
some time. I hope the latest Changes by Marcus fixed that. Please try with
a recent snapshot.
My ggilib is from february or so, didn't want to build a new ggi lib. But
yes, I'll take the time and get me the new one.
I'd like to change the mouse pointer pixmap, how can I do that with ggi?
? GGI has no notion of a mouse-pointer. If you want one, you got to generate
it yourself.
mouse pointer, this image that traveles around the screen, when the mouse
is moved. When I run a ggi programm I get only a white pixel that moves.
If I'm not totatly wrong I remember that I've read some where that the
graphic cards have extra suport for cursors/mouse pointers. As this would
be a hardware feature I expected to gain control with a ggi function. So
there is no
XCreatePixmapCursor
XDefineCursor
XFreeCursor
for ggi?
But if ggi doesn't control the cursor appearance, who decides that in my
ggi apps only a whit dot is drawn?
It sets a rectangle that limits the area that is drawn to. This is interesting
when drawing into divided regions like "windows" or "Cockpits" with
routines that do not necessarily care about giving proper coordinates.
It will inhibit any drawing outside the clipping region. Note, that
Directbuffer access can usually bypass this mechanism.
I did some testruns yesterday, nice!
while ( 1 )
{
if ( ( eventMask = ggiEventPoll( visual, emPtrButton | emKeyPress,
theTimer ) ) 0 )
{
fail( "Error in event poll\n" );
}
Why do I still get events when neither a key nor a mouse button was
pressed???
What kind of events do you get ?
I got emZero's. Strange that this disapeared when I recompiled it.
I want the application to wait for either a mousbutton event or a
keyboard key press event.
I'm not interested in the pointer movement events.
Therefore is set:
if( ggiSetEventMask( visual, emPtrButton | emKeyPress ) != 0 )
{
fail( "Couldn't set event mask\n" );
}
after this I have the main loop that should do something if a mouse
button was pressed or should break the loop if a key was pressed;
It looks like this:
while ( 1 )
{
if ( ( eventMask = ggiEventPoll( visual, emPtrButton | emKeyPress, NULL ) ) 0 )
{
fail( "Error in event poll\n" );
}
if ( ggiEventRead( visual, theEvent, emAll ) == 0 )
{
fail( "Error in reading new event!\n" );
}
if ( eventMask == emKeyPress )
{
break;
}
if ( eventMask != emPtrButtonPress )
{
//should not happen
continue;
}
.. do some stuff
}
running the application showed that if a mouse button was pressed and released
one time, lots of events were received by EventPoll; looking at
theEvent.any.type
showed that there were lots of pointer movement events. But I didn't want
them, I set the event mask so that it shouldn't receive other events
than I want.
Using gdb and looking at
theEvent.pmove.x/y
showed that I seam to get all queued pointer positions befor and after the
mouse press event for the time sequenz where the pointer was in the
window ( I'm using the X target).
I therefore altered the loop so that it reads all similar events out of the
queue:
gii_event_type theEventType;
...
while ( 1 )
{
if ( ( eventMask = ggiEventPoll( visual, emPtrButton | emKeyPress, NULL ) ) 0 )
{
fail( "Error in event poll\n" );
}
if ( ggiEventRead( visual, theEvent, emAll ) == 0 )
{
fail( "Error in reading new event!\n" );
}
theEventType = theEvent.any.type;
while( ggiEventsQueued( visual, emAll ) != 0 )
{
if ( ggiEventRead( visual, theEvent, emAll ) == 0 )
{
fail( "Error in reading new event!\n" );
}
Re: more questions, was: direct buffers, flushing
Hi !
"compressed" lines in the extra space.
But
pixelPointer += stride - mode.virt.x;
should work for all cards?
No. This line can only work for 8BPP. As said, going down one pixel is done
by
(uint *)pixelpointer += stride.
The virtual mode size has nothing to do with that. The demo you probably looked
at uses it, because it will have advanced its pixelbuffer by exactly
mode.virt.x bytes at that time.
My ggilib is from february or so, didn't want to build a new ggi lib. But
yes, I'll take the time and get me the new one.
That would qualify for the known SegV problem.
mouse pointer, this image that traveles around the screen, when the mouse
is moved. When I run a ggi programm I get only a white pixel that moves.
Yes. This is intentional. If you start a GGI program outside X, you will
have no mouse pointer at all. The reason we leave one pixel in X is, that
it helps for your orientation with respect to leaving the program window.
If I'm not totatly wrong I remember that I've read some where that the
graphic cards have extra suport for cursors/mouse pointers.
Yes.
As this would be a hardware feature I expected to gain control with a ggi
function. So there is no XCreatePixmapCursor, XDefineCursor, XFreeCursor
for ggi?
Yes, as this _requires_ Hardware support. We will soon provide an extension
that does this, but it will only work on cards that have hardware support
for it.
But if ggi doesn't control the cursor appearance, who decides that in my
ggi apps only a whit dot is drawn?
GGI itself draws nothing. The change of the X cirsor is only done to get a
consistent look for LibGGI programs. If you want to have a Mouse-Cursor in
LibGGI programs, you have to draw it yourself.
I got emZero's. Strange that this disapeared when I recompiled it.
Hmm - maybe something got miscompiled or you had a buffer overflow somewhere.
after this I have the main loop that should do something if a mouse
button was pressed or should break the loop if a key was pressed;
It looks like this:
while ( 1 )
{
if ( ( eventMask = ggiEventPoll( visual, emPtrButton | emKeyPress, NULL ) )
0 )
{
fail( "Error in event poll\n" );
}
if ( ggiEventRead( visual, theEvent, emAll ) == 0 )
{
fail( "Error in reading new event!\n" );
}
Um - why do you use emAll here ? Please use emPtrButton | emKeyPress like in
the Poll call. The thing you have now will dequeue _any_ event that came in,
as soon as an event that matches the mask in the Poll-call comes in.
theEvent.any.type
showed that there were lots of pointer movement events. But I didn't want
them, I set the event mask so that it shouldn't receive other events
than I want.
No - the event mask is _advisory_. It will disable modules in the Poll-
Sequence that deliver _none_ of the asked-for events. However the mouse does
send both an interesting event (Buttons) and another one.
showed that I seam to get all queued pointer positions befor and after the
mouse press event for the time sequenz where the pointer was in the
window ( I'm using the X target).
Yes. This is correct for the code above. Use the correct Mask for the
EventRead to filter out all the movement events.
Why do I get events that I don't want to get?
Because the Setmask call is advisory.
Is there a better solution?
Yes - calling EventRead with proper evMask.
How do I have to code it when I want to know the position, where the button
press and release event happened?
You track the movement events. The last movement event will be the place the
pointer was clciked at.
Do I have to cache the positions delivered by pointer movement events all
the time and use the last position befor the button press event happened?
Yes.
At least this was the way I did it in a test application and it seamed to
work although moving the cursor around in the window ( again I used the X
target ) caused 30 - 40 percent of cpu load on a Pentium 100. Using top
showed that the X server was the one who consumed the cpu resource.
This is strange. You were drawing nothing ? Maybe your X server has no
hardware cursor ?
I would like to read a rectangular region out of the frame buffer. I
guess that ggiGetBox would help me in what I want to do.
But how should the functions ggiPutBox and ggiGetBox be used in respect of
the buffer that has to be specified?
What size should the buffer have? What type?
man ggiGetPixelFormat
A safe bet for situations where RAM usage isn't critical is
(width+7)*height*sizeof(ggi_pixel)
CU, ANdy
--
Andreas Beck | Email : [EMAIL PROTECTED]
Re: more questions, was: direct buffers, flushing
No. This line can only work for 8BPP. As said, going down one pixel is done by (uint *)pixelpointer += stride. Sorry, TYpo: (uint8 *)pixelpointer += stride. CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED]
Getting there, Was: the GGI-over-/dev/fb blues
Andreas Beck wrote: Um - you read the docs to the end, did you ? It expects -- snip mouse ps2 mdev /dev/psaux -- snip to be in the file. The latter entry can probably be pointed to /dev/mouse, given a proper symlink. I did read the docs, yet it was not obvious that the file should look like the above. Anyway, I did it, then I changed read permissions for /dev/psaux, et voila ! Now a question: when I move the mouse, the queue will fill up rapidly with events. I'd like to be able to 'compress' them, i.e. to only process the last move event from a series. Such a series of course needs to be contigous, i.e. as soon as there is a click or other event, I need to stop compressing since the current mouse position may matter. It would be nice to have such a GGI (GII) function. The simples would be a function which lets me inspect the next event without removing it from the queue, such that I can do the rest myself. Best regards, Stefan PS: it starts to be much fun ! ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Hardware cursors
On Fri, 19 May 2000 [EMAIL PROTECTED] wrote: Hi ! If I'm not totatly wrong I remember that I've read some where that the graphic cards have extra suport for cursors/mouse pointers. Yes. As this would be a hardware feature I expected to gain control with a ggi function. So there is no XCreatePixmapCursor, XDefineCursor, XFreeCursor for ggi? There may be soon. I am considering adding these functions to LibXMI. Since LibXMI is intended to replicate the drawing API of Xlib, they should probably be present anyway. Yes, as this _requires_ Hardware support. Not really. You can do soft-cursors with transparency easily enough, it just isn't very fast. You can hook ggiFlush() to ensure that the cursor is always drawn last. We will soon provide an extension that does this, but it will only work on cards that have hardware support for it. It is easy enought to support it is software too, so why not? Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: Hardware cursors
Yes, as this _requires_ Hardware support. Not really. You can do soft-cursors with transparency easily enough, it just isn't very fast. You can hook ggiFlush() to ensure that the cursor is always drawn last. DirectBuffer ? And how do you "retreat" the cursor before the next drawing command is issued on targets that directly map through (so that there is no backing store ...) ? It is easy enought to support it is software too, so why not? IMHO not, but please prove me wrong. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: Hardware cursors
On Sat, 20 May 2000, Andreas Beck wrote: Yes, as this _requires_ Hardware support. Not really. You can do soft-cursors with transparency easily enough, it just isn't very fast. You can hook ggiFlush() to ensure that the cursor is always drawn last. DirectBuffer ? And how do you "retreat" the cursor before the next drawing command is issued on targets that directly map through (so that there is no backing store ...) ? Hm. OK, perhaps it would be easier to just support cursors when they are hardware accelerated |-. In which case, shouldn't hardware cursor support go in the MISC extension along with WaitRayPos() and SetSplitline(), which are also not supported when not hardware accelerated? There would only need to be two functions, MakeCursor() and SetCursor(), so it seems like overkill to have a whole extension...? It would be very easy to add these two functions quickly to the MISC extension, and lots of targets have accelerated cursor support. LibWMH, LibGWT, LibXMI and Berlin could all use cursor functions Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
