Re: evdev inputs in libgii
Hi, ok, i have found that the combination of removing config.cache, linking /usr/include/linux, and --enable-linux-evdev gets it to say "yes". compilation installation now works just peachy. thanks. O.K. - correct. You did set GGI_INPUT - did you ? yep, i'm using export GII_INPUT=linux-evdev:/dev/input/event0 export GGI_DISPLAY=fbdev:/dev/fb1 Read carefully: You did set GGI_INPUT - did you ? You did set GII_INPUT, but that is ignored in G _G_ I applications, as those never open a GII input with argument NULL, but rather open the additional inputs from GGI_INPUT themselves and join them. So try: export GGI_INPUT=linux-evdev:/dev/input/event0 export GGI_DISPLAY=fbdev:/dev/fb1 unfortunately, after building it through proper means, monitest, and xggi, still fail to access the new keyboard. they access the old "console keyboard" though, so i can still quit the applications. Yeah. Expected behavior, see above. In case you want to do true multihead, you can give the -noinput option to the fbdev target to disable main keyboard, once you have the secondary keyboard running. Oh - and "inputdump" from libggi/programs/utils should help you diagnosing input related problems. other notes: i've also tried /dev/input/event1 (a usb mouse), and it ends up grabbing the /dev/mouse mouse, even though i've given it no command line to use it. This is kinda concerning. The standard mouse and keyboard are autodetermined according to the used target (fbdev in your case) and thus opened. However you can explicitly override the mouse settings in $prefix/etc/ggi/input/linux-mouse (with prefix usually being /usr/local - you will know, if you set it differently). The -noinput will also help, if you want to suppress that "smart" behaviour. be careful when testing USB devices with GGI_INPUT. It can uncover a kernel bug in the 2.4.0-test series USB code that kills the scheduler. My machine has been rebooted many times these last two weeks :) Ouch. Not even Magic SysRq helps a bit in that case probably ... CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: freetype-extension
I'm trying to write an freetype(2.0) - extension for GGI. the problem is, that I've no experience in writing GGI extensions anyone who likes to help me/explain it to me? I'll try to help you when I'm back. Meanwhile maybe Jon can give you some of my old code. Please don't give that to anyone before I have confirmed, that it actually is my code. BTW: Writing a normal Lib (as opposed to an extension) should probably do, as I doubt, that there is much hardware that can accelerate the drawing of text further than accelerated blits from somewhere. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
[ctest@neural.dlsemc.com: Re: evdev inputs in libgii]
- Forwarded message from [EMAIL PROTECTED] - Date: Wed, 02 Aug 2000 15:34:58 -0500 From: [EMAIL PROTECTED] Subject: Re: evdev inputs in libgii To: Andreas Beck [EMAIL PROTECTED] X-Mailer: Mutt 0.95.3i On Tue, Aug 01, 2000 at 06:38:34PM +0200, Andreas Beck wrote: [Ann.: Could you try to make the lines wrap at a suitable place ? TNX.] I tested my USB keyboard by smacking keys on it, while nothing happened. AFAIK this is correct behaviour, as the USB keyboard isn't considered to be a primary input device and thus ignored by the Linux console, which is a design flaw IMHO, but I won't complain any more about the broken design of the Linux console subsystem. actually, you are allowed to insert the module keybdev.o, which will combine it with the main keyboard. but we don't want to do that... we want to do it the manly way ;) Then i typed "cat /dev/Input0", and smacked some more keys strange strings scrolled past my screen showing that the kernel side works. Yes. That sounds good. Then i downloaded the ggi 7/28/00 snaphot, and compiled libggi. when i typed ./configure it said "checking if we should build linux-evdev inputlib ... no". That obviously wasn't good, so i looked in ./configure and found ... some possible options. i tried "./configure --enable-linux-evdev" and ... "./configure--enable-linux_evdev". neither made any differnce. Hmm - CVS isn't responsive right now. I'd have to upgrade to have a look. Usually these should force it. I noticed in config.h that it said i do not have a linux/input.h header file. so i looked and /usr/include/linux/input.h didn't exist, since my glibc6 was compiled with a 2.2 kernel. That's a bit strange. On my system, /usr/include/linux already _is_ symlinked to /usr/src/linux/include/linux ... And I don't think I did this by hand ... i investigated this, and i'm told that the way it's *supposed* to be, is that /usr/include/linux contains the headders that your glibc was compiled with, where as /usr/src/kernel-headders (or whereever you want them) is supposed to keep the headers of your current kernel, for the purposes of creating modules. Now i'm also told that i shouldn't leave /usr/include/linux linked to /usr/src/kernel-headers/... because it can break other apps. (note, i'm running a debian system, so this issue is probably logged somewhere) i tried linking /usr/include/linux to /usr/src/kernel-headers-2.4.0-test4, and that didn't seem to help... don't know why. Did you remove config.cache ? ok, i have found that the combination of removing config.cache, linking /usr/include/linux, and --enable-linux-evdev gets it to say "yes". compilation installation now works just peachy. thanks. at this time i tried setting export GII_INPUT=/dev/Input0, and running mhub. mhub complained that it couldn't load linux-evdev.so. Yeah, as it wasn't compiled. anyway, eventually i just decided to cd to the linux-evdev directory, and typed "make; make install", which successfully made the target and installed it in /usr/local/... In that case configure was at fault. If it wasn't the "stale config.cache" problem, we should investigate. I tried running mhub and while it no longer complined about finding linux-evdev.so, i couldn't figure out what mhub was supposed to do, so it wasn't a good test of the keybaord ;) Mhub is a mouse-translator. Then i ran monitest, and it totally ignores the evdev device, and uses the main keyboard. What am i doing wrong? You did set GGI_INPUT - did you ? yep, i'm using export GII_INPUT=linux-evdev:/dev/input/event0 export GGI_DISPLAY=fbdev:/dev/fb1 (/dev/input/event0 is a link to /dev/Input0, which i've tested) also, i've run as root, to show it's not a permission problem. unfortunately, after building it through proper means, monitest, and xggi, still fail to access the new keyboard. they access the old "console keyboard" though, so i can still quit the applications. other notes: i've also tried /dev/input/event1 (a usb mouse), and it ends up grabbing the /dev/mouse mouse, even though i've given it no command line to use it. This is kinda concerning. *note** be careful when testing USB devices with GGI_INPUT. It can uncover a kernel bug in the 2.4.0-test series USB code that kills the scheduler. My machine has been rebooted many times these last two weeks :) The usual syntax is "GGI_INPUT=target:options" btw. Also always mind the difference between GGI and GII. (after getting this all written, i just realized a question. does monitest use GII? if not, what programs do?) All LibGGI programs implicitly use LibGII, unless you do really weird contortions to avoid it. However they use their own way of detecting the right inputs to use for a given display type, so they also have their own override variables. CU, ANdy -- = Andreas Beck
anonymous cvs access
Hi there I sent this to [EMAIL PROTECTED] but got no response. Can anyone help? Cheers On Tue, 01 Aug 2000 13:46:21 Bob Ham wrote: Hi there I've been trying to get ggi cvs for the last few days, but I always get this message: node@insanity:~/proj/t$ cvs -d:pserver:[EMAIL PROTECTED]:/cvsdevel login (Logging in to [EMAIL PROTECTED]) CVS password: cvs [login aborted]: connect to anoncvs.us.ggi-project.org:2401 failed: No route to host and: node@insanity:~/proj/t$ ping anoncvs.us.ggi-project.org PING anoncvs.us.ggi-project.org (209.251.120.6): 56 data bytes --- anoncvs.us.ggi-project.org ping statistics --- 10 packets transmitted, 0 packets received, 100% packet loss It looks like something's a bit wrong. -- Bob Ham: [EMAIL PROTECTED] http://flux.mentaltempt.org/~node/ IRC: 'Bob' on irc.openprojects.net: #Slashdot ICQ: 4396425 'The Tek' 27699423 'The Tek.' Time City Level Designer Time City: http://www.timecity.org/ My work: http://flux.mentaltempt.org/~node/tc/
colors vs. pixels
I have some simple questions concerning pixel manipulation in GGI: I understand that the mapping between pixels and colors depends on the visual type being used. Supposing that we deal with TrueColor visuals exclusively in the following. If I querry the pixel format, it appears I can write any RGBA value into a pixel buffer I want. The ggiMapColor and family seem only convenience (again, when using TrueColor). Is this right ? Further, the GGI color model doesn't deal with alpha channels (from the docs). What if I specify the alpha value in the pixels directly ? Is this simply ignored when I issue a ggiPutBox call ? Or can I use the alpha value to put a shaped (masked) region ? Regards,Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: problems with ggi/gii keyboard handling
Chris Arena wrote:
_giiPollall calls ...
gii_event_mask
_giiPollall(struct gii_input *inp, gii_event_mask mask, void *arg)
{
retmask |= (curr-GIIeventpoll(curr, arg) mask);
where the NULL from above is now the value for the void * arg.
The routine at curr-GIIeventpoll( ... ) isn't debugable, so I don't
know where that goes.
As far as I can read in the sources, every device-driver initializes its
gii_input structure in a function like GIIdlinit (see e.g.
.../libgii/input/linux_kbd/input.c). In the case of the keyboard-driver the
function pointer GIIeventpoll should then point to
GII_keyboard_poll(gii_input*,void* arg) where arg is treated as a pointer
to an fd_set if not null.
Hm... The only file I find with calls to ggLock/ggUnlock is
.../libgii/input/gii.c. The mutex given as argument should always exist -
it belongs to the event queue (and is always allocated in
_giiEvQueueAllocate - _giiInputAlloc - giiOpen) or it is the mutex
_gii_safe_lock (allocated in giiInit, file .../libgii/gii/init.c).
So ggLock is called on the mutex of a queue that already has been deleted?
Oh - MAINTAINER OF GII: function giiClose in file .../libgii/gii/gii.c:
_giiEvQueueDestroy (*) is called two times (should do no harm though)!
int giiClose(struct gii_input *inp)
{
struct gii_input *curr = inp;
(...)
_giiEvQueueDestroy(inp); /* This destroys _all_ queues ! */ -- first
time
do {
struct gii_input *prev;
curr-queue = NULL; /* For better error catching. */
if (curr-GIIclose) {
rc = curr-GIIclose(curr);
}
if (curr-dlhand) {
_giiCloseDL(curr-dlhand);
free(curr-dlhand);
}
prev = curr;
curr = curr-next;
_giiInputFree(prev); - second time: _giiInputFree calls
(*)
} while (curr != inp); /* looped through once. */
C.u. Martin
Re: screen update issues with xggi, monitest, and other apps.
On Wed, Aug 02, 2000 at 11:56:30PM -0400, Steve Cheng wrote: On Wed, Aug 02, 2000 at 06:06:12PM -0500, [EMAIL PROTECTED] wrote: i've noticed a problem which i originally noticed when running multi-user quake on one machine. When i load XGGI (or monitest, or whatever) on screen #0, then switch to a application that runs on screen #1 (like console bash), the screen will stop updateing. Now i have tested and can show that the process is still processing, by hooking in a alternate input source (read: second keyboard) and doing a "ls -R" in a Xterm, and listen to the hard drive thrash. however i'd like see my file list go by on screen #0 as i'm working on screen #1. is there some code, that specifically prevents updateing the graphics of one VC while in another? is there any way to get around this? I thought that LibGGI already has the correct behavior (whatever that is -- I'll let the resident masters answer), I can confirm that if I start quake-ggi and switch to another VC *before it actually sets graphics mode* (initialization, etc.), LibGGI will assume that it is on the correct VC already and draw on the wrong virtual console. that's interesting. That seems to be contrary to what i'm getting. I now have a setup with 2 XGGI sessions running. XGGI :0.0 is running with a USB keyboard, and USB mouse on a matrox fbdev /dev/fb1. XGGI :1.0 is running with a ps2 keyboard, a ps2 mouse, on a matrox fbdev /dev/fb0. when i type things on the USB keyboard and hit enter, i can still hear the hard drive thrash, as it searches for the files. But nothing new shows up on the screen, i just keep the last X image that i had from a while back on the screen. If i switch VC's with my ps2 keyboard, over the the XGGI:0.0 VC, the results of my last command will suddenly display. i'm running libgii and libggi snapshots from 08/02/00. i don't really understand what causes this, but i can imageine either some kind of "optimization" that is trying to save time for "background" processes, or a "safety" to not have background processes write on the screen, which you seem to have evidence against. we'll have to keep gathering evidence. (i've broke the dependancies on my machine cause of compiling libggi/libgii, and can't get quake to install to test that right now. How do you get the application to delay between VC swtich, and before it starts graphics mode?) hmm, i see a lot of libraries that i haven't installed. (libgic, libxmi, libgffd, etc) they wouldn't be realted to basic console functions would they? Corey
Re: the docs are wrong!
after 2 weeks i finally figured it out. ../lib/libgii/doc/env.txt should read: GGI_INPUT=linux-evdev:/dev/input/event0 *not* GII_INPUT=linux-evdev:/dev/input/event0 To confuse you more: The docs are right. As I explained in my other mail, GII_INPUT only acts on _pure_ LibGII Applications that use giiOpen(NULL); . LibGGI on the other hand does never use giiOpen with a NULL argument, but it will giiOpen(); anything you give in GGI_INPUT or the variant GGI_INPUT_targetname, as documented in libggi/doc/env.txt and will giiJoin() it with the other inputs it opened due to target specific considerations. So the rule is: - Pure LibGII application: Use GII_INPUT. - LibGGI application: Use GGI_INPUT. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
