RE: ggiPutBox
Hi You are right. IMHO The good idea is to add it to documentation. Did you read my message for line clipping recycling loop values? Best Regards, Dmitry Semenov EMail: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marcus Sundberg Sent: Thursday, February 10, 2000 1:45 AM To: [EMAIL PROTECTED] Subject: Re: ggiPutBox "Dmitry Semenov" [EMAIL PROTECTED] writes: I'm sorry if it is a well-known bug or already fixed one. Default implementation of ggiGetBox ignores clipping settings. It can cause core dump in case of broken :) values. Hi, That's actually a design decission. You really don't want ggiGet* to clip, and in 99.99% of the cases you will pass valid values to it. The remaining 0.01% of the cases you can make a pre-clipping wrapper, which will not induce any overhead for the common case. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Line Clipping
Hi I found that standard GGI line clipping getting perpetual loop with some arguments. It was while using these arguments: 568, 383, 49360, and 1234 for clipping area 100, 3, 1019, 766. May be it was different because I found it written in my notebook but sure only for 90%. Anyway it was close enough. It happened because of overflow in line formula. Solution is: just break the perpetual loop. It's not necessary there. Also I found that Matrox G100 acceleration is slowly than software drawing. That's it. Best Regards, Dmitry Semenov EMail: [EMAIL PROTECTED] Web: www.chollian.net/~hatter -Original Message- From: Rubén [mailto:[EMAIL PROTECTED]] Sent: Friday, January 28, 2000 7:36 AM To: [EMAIL PROTECTED] Subject: Re: SGI OpenGL freely avalibale. On 2000/Jan/27, Steffen Seeger wrote: Dynamic assembly code generation for rasterization is not yet included, making software rendering performance slow. Interesting, we came about the same technique as SGI: The GGL code in KGI-0.9 was a code-study how to dynamically ^^^ What do you refer to with GGL? :) -- _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ] ^^^
RE: CT65555
Today I found CT65550 frame buffer source in 2.2.14 kernel tree. Does it work or no? -Original Message- From: Steffen Seeger [mailto:[EMAIL PROTECTED]] Sent: Monday, January 01, 1601 9:00 AM To: [EMAIL PROTECTED] Subject: Re: CT6 I've contacted to author of the CT driver. He told me that it is 2years old sources. So I have no idea now where can I get driver. Worst case will be writing a driver by myself. But I have no time at all :(. Dmitry I have a CT 6 in my laptop I planned to support once the P2 driver is reasonably finished (accelerated X). But this is some time away. Steffen - e-mail: [EMAIL PROTECTED] -
WiP 0.2
Everybody is welcome to check out the www.chollian.net/~hatter and try out that software The ideas of WIP are: 1. To bring really EASY interface for the developers(at least to myself) making GUI based software. 2. To give possibility simply using of existing objects in concrete way. 3. To use only what you need. If you have not enough objects simply define new one. 4. A topic 3 is very close to the Builder, Delphi ideas but you do not need any language extensions and any deriving from some classes. 5. To avoid using big windowed systems like X or Windows. That is really useful in many cases 6. To achieve rapid graphics to give possibility making Games, Web-Browsers, ... 7. To give possibility to be really independent on platform you use. 8. To make Multilingual interfaces. (This version includes Cyrillic, Korean, English output). I have Korean input code still not ported as well as any language other. Best regards, Dmitry Semenov
FW: problems over matrox fb
Hi I've just tested vesafb. I've found no problems. So I believe there is a bug inside of some acceleration function(s). The question is where is it, in GGI or matroxfb or my G100 board? If any one has matrox board working with accelerator matroxfb please test ggiDrawBox and ggiDrawLine in 16 bit 1024x768 F2 mode. Write frame should be invisible, read frame is opposite, please use clipping 0, 0, 1027, 768 and draw functions arguments like these -10, 10, 200, 200. Flip it and see results after drawing. I do believe the problem is when using the other settings as well, but these settings have problems exactly at least for my board. I use the May release version of ggi. If this is my mistake please let me know:) Dmitry -Original Message- From: Dmitry Semenov [mailto:[EMAIL PROTECTED]] Sent: Monday, November 01, 1999 2:42 PM To: [EMAIL PROTECTED] Subject: FW: problems over matrox fb I'm sorry to send this message ones more. I still have no any answer. Additional info. I use Matrox G100 with 4meg memory May be is a good idea to add an accelerator functions trigger in GGI interface to give possibility to switch off some accelerator function in case of bad hardware. Best regards. Dmitry -Original Message- From: Dmitry Semenov [mailto:[EMAIL PROTECTED]] Sent: Friday, October 29, 1999 4:17 PM To: [EMAIL PROTECTED] Subject: problems over matrox fb Hi I'm sorry if this is well known problem I use LibGGI 2.0beta2 I've just tested some ggi drawing function over matrox fb. I tested 1024x768 F2 with full screen clipping and also partly screen clipping(something like 10, 0, 1024, 768). I've found that DrawLine and DrawBox(at least) function have problems when first (at least) coordinate X is negative. Sample: ggiDrawLine(-10, 20, 90, 120); ggiDrawBox(-10, 20, 100, 100); line left top end is pointed somewhere else -10, 20 Box disappeared from the screen I have no problem with X target. I never tested vesafb. Best regards, Dmitry
Just one more problem with matroxfb G100
I've found the color losing when was doing ggiCrossBlit Mode 1024x768 F1 16/16 Source: memory device the same format contains RGB( 0xDD, 0xDD, OxDD) pattern with some black lines and text and all of it packed into 16 bit device. Calling: GgiCrossBlit(mem, 0, 0, 1024, 768, video, 0, 0 ); Made screen blue Calling memcpy(...) has done job well. I think there is a problem :). Best regards, Dmitry
FW: problems over matrox fb
I'm sorry to send this message ones more. I still have no any answer. Additional info. I use Matrox G100 with 4meg memory May be is a good idea to add an accelerator functions trigger in GGI interface to give possibility to switch off some accelerator function in case of bad hardware. Best regards. Dmitry -Original Message- From: Dmitry Semenov [mailto:[EMAIL PROTECTED]] Sent: Friday, October 29, 1999 4:17 PM To: [EMAIL PROTECTED] Subject: problems over matrox fb Hi I'm sorry if this is well known problem I use LibGGI 2.0beta2 I've just tested some ggi drawing function over matrox fb. I tested 1024x768 F2 with full screen clipping and also partly screen clipping(something like 10, 0, 1024, 768). I've found that DrawLine and DrawBox(at least) function have problems when first (at least) coordinate X is negative. Sample: ggiDrawLine(-10, 20, 90, 120); ggiDrawBox(-10, 20, 100, 100); line left top end is pointed somewhere else -10, 20 Box disappeared from the screen I have no problem with X target. I never tested vesafb. Best regards, Dmitry
RE: GII event system
Hi
I just got one device which will be not so good to drive with your
conception of dividing space and click data:
This is touch screen. I think you used bank machines or something like that
:)
Best Regards. Dmitry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 22, 1999 3:05 AM
To: [EMAIL PROTECTED]
Subject: Re: GII event system
Hi !
1. Mouse is a human input device, as well as others pointing device.
Practically buttons are related to mouse position and usual human expects
reasonable button action right in place where he has clicked it.
Yes. This however does not mean, that the driver producing the "clicks" has
to know anything about the driver producing the moves.
This is why the moves and clicks are separate. Please note, that it is
possible to mix relative and absolute pointer events. A simple example of
that would be keyboard emulated mouse (which only makes sense as relative
events) on a absolute-mouse target like X.
What have we do with GII. Something like that collecting:
pmove1 abs
pbutton
pmove2 abs
will do
(pmove1.x +pmove2.x)/2 and the same for y.
??? What ?
I'll sketch how a LibGGI mouse handling routine for a system that expects to
work with absolute coordinates is intended to look like:
{
static int mousex,mousey;
...
ggiEventPoll(vis, emKey|emPointer, NULL);
events = ggiEventsQueued(vis, emKey|emPointer);
while (events--) {
ggiEventRead(vis, event, emKey|emPointer);
switch(event.any.type) {
case evPtrButtonPress:
switch(event.pbutton.button) {
case GII_PBUTTON_FIRST:
do_something_as_appropriate(mousex,mousey);
break;
case GII_PBUTTON_SECOND:
...
}
break;
case evPtrButtonRelease:
... if needed ...
break;
case evPtrAbsolute:
mousex = event.pmove.x;
mousey = event.pmove.y;
break;
case evPtrRelative:
mousex += event.pmove.x;
mousey += event.pmove.y;
break;
}
/* Constrain mouse in any case */
if (mousex 0) mousex = 0;
if (mousey 0) mousey = 0;
if (mousex xmax) mousex = xmax;
if (mousey ymax) mousey = ymax;
} /* while */
}
As you can see, this nicely symmetriyes the cases of abs and rel events.
Basically the same can be done for apps that expect relative events, though
those might get trouble on absolute input data when trying to "keep turning
left" or similar.
Was it good? It is no good, at least because gii client software is not
right place to do it.
To do what ? (pmove1.x +pmove2.x)/2 ? There is no reasonable place to do
such a calculation at all. To make sense at all, you would have to make a
weighted mean based on the time between the individual event's timestamps.
There is no assumption of something like a linear motion between points
between move events, and for sure no assumption, that the click happens in
the middle of that.
The expected behaviour is, that the above used mousex,mousey variables
express the correct position of the pointer, when a click comes in.
If the mouse was moved between the last move and the click, the driver is
expected to send another move and then the click to correctly position the
pointer before transmitting the click.
Why do I need to keep every pmove message until get
pbutton and pmove again? That is not pretty at least.
You don't. See above. In case that delivers incorrect results, we have a bug
in a driver or backend and need to fix the driver or flame the backend
authors.
I understand that it is my task to determinate correct click place in
case
of relative move messages and I do. But I really hope I will be able to
avoid mouse cursor software emulation(what I have done because of no
choice)
and to forget about relative messages for pointing device like mouse in
the
future when GGI will take care about hardware cursor.
GGI will never take away the information you get from the input device.
While we may provide a method to place a hardware sprite on the display,
thus allowing to easily make up a mouse pointer, this will not influence
the pointer data sent from the input device.
I repeat ones more I am discussing only about the case when cursor
generation is not my task.
I still do not get what cursor generation has to do with input handling.
There are some applications that would be pretty unhappy, if we converted
all input to absolute pointer events. Guess why the X target has the
relmouse mode ...
In the depth My question was why after calling poll(I call it with 0 time
delay) the queued function shows only one message we have inside of
queue but actually there are many (inside of some internal buffers).
If that is the case, this is a bug and should be fixed.
I think poll function really poll only one message for each message type
per one call, does not it?
No. It should check and queue all attached inputs, and all inputs
GII event system
1. Why GII gii_event.pbutton does not have cursor coordinate information in
case of GII buffering and sending data which have absolute cursor position(x
target and may be future fb target with hardware cursor).
2. Why GII does not use button data in case of sending pmove event?
3. I found some strange behavior inside of GII.
-I poll GII one time
-I read all events queued inside GII in my internal buffer with keeping
only onepmove message inside of my buffer
-I read one message from my buffer.
-I move my cursor in case of pmove data
-I call ggUSleep(10);
-I see funny effect on the screen:
my cursor making always is to late :) It looks like GII buffer can not
giveme back all messages by one polling.
if I do poll and read queued messages like this:
while(Poll()); instead of one polling
where Poll is something like this. (DO not forget I do not save reputed
pmove messages. I cleaned that code to save space.)
bool wipGII::Poll()
{
bool r=false;
timeval val;
val.tv_sec=0;
val.tv_usec=0;
ggiEventPoll(graph-vis, emAll, val);
for (int n=ggiEventsQueued(graph-vis, emAll); n; n--)
{
ggiEventRead(graph-vis, ev[(unsigned char)(ev_ptr+ev_qty)], emAll);
if (ev_qty!=0xff) ev_qty++; else ev_ptr++;
r=true;
}
return r;
}
I've found no problem with my cursor.
Thank you
Dmitry
RE: GII event system
Hi
Ok,
1. Anyway that is no so big problem if you do not want to keep space data
together with buttons.
As I got from you message you can guaranty last pmove message(s) contains
right data for the determination of pointer position in the time of
clicking. It's more than enough. By the way my code is looks like the same
of yours except I avoid of calling 3rd party libraries directly and I use
own wrappers. My experience showed me that code for really good system has
to be not depended from any other library(thats funny when I see MFC
programmers who made software(and own brain) absolutely mot portable). I
make semi-embedded software like navigational systems, marine simulators.
Ask me how many libraries graphics libraries and input system I changed for
the last 10 years? A lot of. Know I can just make one more wrapper over
existing libraries and keep my other code just untouchable.
Absent of space data and click data made me a little confused because GGI is
the first library I have seen making this dividing :)
2. Event generation has not so many to do with cursor generation. But If GGI
library do not provide cursor monitoring and generation of it the GGI users
have to do this job manually. IMHO it will be nice for many users of really
nice GGI, if GGI will work together with GII to provide mouse cursor
monitoring when GGI will get hardware cursor access.
3. Marcus already gave some explanation for the Poll. Thanks. May be letter
it will good to show my code as one more gui development system using GGI.
Best regards, Dmitry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 22, 1999 3:05 AM
To: [EMAIL PROTECTED]
Subject: Re: GII event system
Hi !
1. Mouse is a human input device, as well as others pointing device.
Practically buttons are related to mouse position and usual human expects
reasonable button action right in place where he has clicked it.
Yes. This however does not mean, that the driver producing the "clicks" has
to know anything about the driver producing the moves.
This is why the moves and clicks are separate. Please note, that it is
possible to mix relative and absolute pointer events. A simple example of
that would be keyboard emulated mouse (which only makes sense as relative
events) on a absolute-mouse target like X.
What have we do with GII. Something like that collecting:
pmove1 abs
pbutton
pmove2 abs
will do
(pmove1.x +pmove2.x)/2 and the same for y.
??? What ?
I'll sketch how a LibGGI mouse handling routine for a system that expects to
work with absolute coordinates is intended to look like:
{
static int mousex,mousey;
...
ggiEventPoll(vis, emKey|emPointer, NULL);
events = ggiEventsQueued(vis, emKey|emPointer);
while (events--) {
ggiEventRead(vis, event, emKey|emPointer);
switch(event.any.type) {
case evPtrButtonPress:
switch(event.pbutton.button) {
case GII_PBUTTON_FIRST:
do_something_as_appropriate(mousex,mousey);
break;
case GII_PBUTTON_SECOND:
...
}
break;
case evPtrButtonRelease:
... if needed ...
break;
case evPtrAbsolute:
mousex = event.pmove.x;
mousey = event.pmove.y;
break;
case evPtrRelative:
mousex += event.pmove.x;
mousey += event.pmove.y;
break;
}
/* Constrain mouse in any case */
if (mousex 0) mousex = 0;
if (mousey 0) mousey = 0;
if (mousex xmax) mousex = xmax;
if (mousey ymax) mousey = ymax;
} /* while */
}
As you can see, this nicely symmetriyes the cases of abs and rel events.
Basically the same can be done for apps that expect relative events, though
those might get trouble on absolute input data when trying to "keep turning
left" or similar.
Was it good? It is no good, at least because gii client software is not
right place to do it.
To do what ? (pmove1.x +pmove2.x)/2 ? There is no reasonable place to do
such a calculation at all. To make sense at all, you would have to make a
weighted mean based on the time between the individual event's timestamps.
There is no assumption of something like a linear motion between points
between move events, and for sure no assumption, that the click happens in
the middle of that.
The expected behaviour is, that the above used mousex,mousey variables
express the correct position of the pointer, when a click comes in.
If the mouse was moved between the last move and the click, the driver is
expected to send another move and then the click to correctly position the
pointer before transmitting the click.
Why do I need to keep every pmove message until get
pbutton and pmove again? That is not pretty at least.
You don't. See above. In case that delivers incorrect results, we have a bug
in a driver or backend and need to fix the driver or flame the backend
authors.
I understand that it is my task to determinate correct click place
RE: GII event system
Dear Marcus
Well, this is only a problem for broken or really strange apps, but
I think we should still provide a way around it:
This is of semantic problem. IMHO When I call something like Poll at first
and GetQueued I expect (very deep inside of my mind) to get all events
"already" buffered by an input library. As I told it was not a problem. It
seemed strange to me behavior like that because it is different from
expected by me.
Of course software uses only GII buffering will never understand this
problem. But Any software uses own buffering immediately get it. You can ask
me why do I need to use own buffer? Let se some my explanation provided to
Andreas under topic 1.
Thanks
Dmitry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marcus
Sundberg
Sent: Friday, October 22, 1999 8:19 AM
To: [EMAIL PROTECTED]
Subject: Re: GII event system
Andreas Beck wrote:
In the depth My question was why after calling poll(I call it with 0
time
delay) the queued function shows only one message we have inside of
queue but actually there are many (inside of some internal buffers).
If that is the case, this is a bug and should be fixed.
I think poll function really poll only one message for each message type
per one call, does not it?
No. It should check and queue all attached inputs, and all inputs should
read their sources until they are drained.
Well, this is only a problem for broken or really strange apps, but
I think we should still provide a way around it:
Let gq be the number of events queued in LibGII and kq be the number
of events queued in the kernel.
Initial state: gq = 0, kq = 3
giiEventPoll() is called == fetches all events == gq = 3; kq = 0;
giiEventRead() is called, but only twice == gq = 1; kq = 0;
Now the user moves the mouse arround == gq = 1; kq = 5;
giiEventPoll() is called == as gq 0 no events are fetched from kq
into gq. This is 100% correct due to performance reasons, BUT:
When giiEventsQueued() is called and returns the number of events in
the queue you get 1 allthough there are more events that could be
read.
My suggestion is that we add a new function
int giiQueuedAfterPoll(struct gii_input *inp, gii_event_mask mask);
which will first poll all relevant input sources, regardless of the
number of events queued, and then return the number of events available.
When I think of it we should definitely add this function, because
it will allow the following common code:
struct timeval tv = { 0, 0};
if (giiEventPoll(inp, mask, tv)) {
n = giiEventsQueued(inp, mask);
while (n--) {
giiEventRead(inp, ev, mask);
process_event(%ev);
}
}
to be replaced with:
n = giiQueuedAfterPoll(inp, mask);
while (n--) {
giiEventRead(inp, ev, mask);
process_event(%ev);
}
Unless there are any objections or suggestions for a better name
I'll add this function to LibGII (and it's companion in LibGGI).
//Marcus
--
---+
Marcus Sundberg| http://www.stacken.kth.se/~mackan/
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
RE: GGI using
Thank you very much. That helped. I never tried ypan option before because of vesafb.txt has string about ypan like this: "This is default". Now I have only one problem. How to set-up refresh rate over vesafb since fbset can not do any with that one. Best regards. Dmitry -Original Message- From: Andrew Apted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 13, 1999 3:58 PM To: [EMAIL PROTECTED] Subject: Re: GGI using Andy writes: also I can not set F2 mode. Yes. This is as well not possible with VESAfb. It cannot pan. There is a kernel command line option to enable panning for VESAfb. Put this in the LILO config or GRUB menu.lst or whatever: video=vesa:ypan 2. How to use vesafb with multi-frames You can't. Only with the `ypan' option, as above. Cheers, __ \/ Andrew Apted [EMAIL PROTECTED]
RE: GGI using
Thanks for the help I really used mc. I will check. But I do not understand why there is a difference in behavior when I use root login and usual user. I need page-switching. What target can you recommend me instead of matroxfb? I have matrox board but I do not like to make software working only on specific hardware. I cant use X. Of course I can emulate page-switching but that is bad. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 12, 1999 7:53 PM To: [EMAIL PROTECTED] Subject: Re: GGI using Hi ! when I start under root I've got normal behavior and error output: Under usual user I've got error output: display-fbdev: ioctl(VT_GETSTATE) failed: Invalid argument L/vtswitch: open /dev/vc/8: No such file or directory Linux-kbd: Couldn't open TTY: Device not configured display-fbdev: Unable to open linux-kbd, trying stdin input. Do you run your programs from something like mc ? This usually causes that problem. If not, please strace the program to see what call fails and why. Also gpm mouse is always on the screen. This is the logical consequence of the above. If the linux console input system can not be activated, the console cannot be put into "graphics mode" which results in text still going to console (interfering with graphics) and GPM being active. If I do not touch any key or mouse there are no problems except one. Sometimes I can see text cursor blinking in down part of the screen. Yes. Same reason as above. When I'm going to switch consoles my program is drawing over these consoles. Yes. This is again caused by not being able to attach to the linux-keyboard system which takes care for consoleswitch handling. And also program completely loses parent console background. Yes. Same problem. About vesafb. When I start Linux using vesafb on the same configuration I can not run my program in F2 mode as well as I can not run GGI demo programs in the same mode or using virtual screen. Yes. See my other mail about that vesafb cannot change modes. CU, Andy -- Andreas Beck | Email : [EMAIL PROTECTED]
RE: GGI using
Thank you very much for you answer. I will explain the situation more. The first of all here is some info about inputdump program Environment: Celeron 450 96 Mb memory Matrox G100. Linux Red Hat 6.0 usual installation without kernel recompiling. Matroxfb is loaded as module in /etc/rc.d/localinit.d instmod matroxfb fbset xga16 -a where xga16 is my setting for 1024x768 16bit Svgalib is not intalled. when I start under root I've got normal behavior and error output: Under usual user I've got error output: display-fbdev: ioctl(VT_GETSTATE) failed: Invalid argument L/vtswitch: open /dev/vc/8: No such file or directory Linux-kbd: Couldn't open TTY: Device not configured display-fbdev: Unable to open linux-kbd, trying stdin input. Also gpm mouse is always on the screen. when I run my program I've got stderr output: display-fbdev: ioctl(VT_GETSTATE) failed: Invalid argument L/vtswitch: open /dev/vc/8: No such file or directory Linux-kbd: Couldn't open TTY: Device not configured display-fbdev: Unable to open linux-kbd, trying stdin input. 1024x768.V1024x768.F2.D1x1.[C16/16] My program draws some lines boxes over a screen within 10 sec. it stops after. If I do not touch any key or mouse there are no problems except one. Sometimes I can see text cursor blinking in down part of the screen. When I'm going to switch consoles my program is drawing over these consoles. And also program completely loses parent console background. When I ran inputdump using root I also had problems with loosing of background. There is no problem with switching between consoles except that one. About vesafb. When I start Linux using vesafb on the same configuration I can not run my program in F2 mode as well as I can not run GGI demo programs in the same mode or using virtual screen. Best regards, Dmitry -Original Message- From: James Simmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 12, 1999 8:18 AM To: [EMAIL PROTECTED] Subject: Re: GGI using Matrox(G100 4MB) Frame buffer. Problem is I can not operate with GGI input without super user privileges. Weird. Never had this problem. Other problem that every console uses the same fb. How many vidoe card do you have? Their is normally one video for all virtual terminals. If you have more than one video card that uses fbdev then you can use a utility called con2fb to map consoels to a particular video card. How I can stop text cursor, gpm, loosing picture when switching between consoles? Starnge. Never had this problem. I switch all the time between Mesa-GGI and my nice fbcon termninal. (By the way may be some one knows. I load matroxfb as module and have problem with gpm. My text mouse catches only 80x25 moving range instead of 132x..(i use 1024x768)) VESA Frame buffer(using vesa 2.0 over Matrox G100 4MB) I can not set modes: x.Vx where and are the all possible combination also I can not set F2 mode. Hum. These are fbcon bugs. More like console code bugs. I have sent this to the fbdev list. When vesafb is loading at the boot time I can see(or inspect log)that frame buffer is set 1024x4824 .I can be wrong with exactly remembering of the last dimension. This is right. Fbcon allocates all the video memory. This enables nice scrolling. Could you show me any way how to use vesa fb with multiple frames? I believe with GGI you can allocate more than one frame when you set a mode. To cut a long story short my basic questions are 1. How to use ggi input with framebuffer target without root privileges I never seen this before. 2. How to use vesafb with multi-frames You shouldn't have to worry about this.LibGGI does this for you. 3. How I can stop text cursor, gpm, loosing picture when switching between consoles? some additional 4. I would like to get hardware mouse cursor. LibGGI has no cursor support as of yet. This falls under the area of sprites but I haven't heard anything recently on this.
RE: ggiFlush
Thanks I've used the times function insted. clock has different behavior. It gives of using cpu time :). Sorry for make troubles to you. Everyone uses clock to determinate time between two events under win32 and dos. A porting problem. Best regards, Dmitry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, October 04, 1999 10:02 PM To: [EMAIL PROTECTED] Subject: Re: ggiFlush Hi ! I am sorry to make troubles to you with my carzy outlook software. Is this message ok? Perfectly nice. Thanks ! About my question. Look at my code attentivily. That piece of shit has to run not more not less than 10 sec. It should nod deppend on the target. What is strange that function clock returned wrong result depending on GGI mode. Oops - that is weird. I admit I hadn't looked closely enough at your code. Just saw some timing loop and thought it would be a run-this-x-times-and- measure-the-time type speed check. Sorry, I have already deleted your mail form the incoming folder, so I can't look at it in detail anymore, but I can try to give a few possible explanations. I suppose you do a run-this-for-xx-seconds-and-count-how-often- you-get-it-done type check - right ? a) For X in sync mode, we are heavily messing with strange stuff like sending signals to the main process from a helper child to allow for the asynchronous (with respect to program execution) redraws. However this should not interfere with the clock() function. It does interfere with sleep() and friends, however. b) For X in ASYNC mode this cannot be the cause. If we don't have an array overflow or something, I suspect it is c). c) from man clock: clock() returns the amount of ***CPU time*** ... The time reported is the sum of the user and system times of the calling process ... In X, we have a client-server model. That means you do not get the whole CPU for your program anymore, as the X server has to do the actual drawing. That will account for _the_X_Server's_ CPU time. Thus it is possible for the loop to take 10 seconds of _real_ time, while the process only has the CPU for 10 seconds of that time. Letting top i run in a second xterm should allow to check that theory. It should show about 50-70% CPU for the X server and the rest for your program (and a bit for top and other stuff of course). CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED]
RE: FW: problems over matrox fb
Ok Thanks, It's not a big problem. Just now I've added support for back buffer additionally to paging mode. GGI default functions work well. Best regards, Dmitry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, November 05, 1999 2:22 AM To: [EMAIL PROTECTED] Subject: Re: FW: problems over matrox fb Hi ! I've just tested vesafb. I've found no problems. So I believe there is a bug inside of some acceleration function(s). The question is where is it, in GGI or matroxfb or my G100 board? Well basically it is probably the GGI lib that accesses the matroxfb not checking for conditions the G100 chip will not handle gracefully in hardware. You might want to try disabling the matrox acceleration driver in /etc/ggi/targets/fbdev.conf . CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
