switching or mansync that
is used in targets that need to simulate SYNC mode.
Always needed functionality might be better placed in a private function of
the core library.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
plied to
a pointer
> +int giiSplitInputs(struct gii_input *inp, struct gii_input **newhand,
> +uint32 origin, uint32 flags)
:-) Again I trust you on that one.
I assume you will add a few functions/macros making use of the new split
functionality to LibGGI as well ?
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
user:
#!/bin/bash
su "$1" -l -c "$(xauth list $DISPLAY | sed -e "s/^/xauth add /"); exec $SHELL"
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
No - wait the first ":" in "display-x::0.0" is the field separator, the
second one is the one from $DISPLAY.
If it is a parsing problem, you should check if it happens with
GGI_DISPLAY="display-x::0.0" (works for me).
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
n.
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
heck the other LibGGI demos like "demo" or "flying_ggis" ?
If those work, it is very likely, that dviv contains some sort of buffer
overflow which causes it to freak out at that place.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
that right.
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
wanted to restore the image;
> and that would be prohibitively expensive.
Not really, but linux vc switching doesn't facilitate that nicely. The old
scrdrv patches did it ... though it was a bit umm strange *g*
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
cepts them e.g.) hmmm
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
; the G400 hack on it yet, perhaps same problem...
What happens on MGA1064 ?
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
nges to the
draing primitives might be needed to get them to draw to the right frame.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
galib/mode.c (/* DirectBuffers */) and for the other case,
you just manipulate all primitives to look like
- vga_drawpixel(x, y);
+ vga_drawpixel(x, y + vis->w_frame_num*frame_height);
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
Brian, just to let you and the list know:
Your Detach-Input patch works fine with my 4-Window app. TNX
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
without-cywin" ?
I doubt too many people will want the native windows option except for
licensing problems with Cywin.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
the timeframe - I'd say if it's below two weeks extra time, I'd
rather wait. Gives much broader audience.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
dded, there are no
compatibility issues with older apps. As probably noone except me is using
LibWmh, I suppose there won't be any problem for newer apps encountering an
old LibWmh as well.
Further ideas to add to LibWMH: Add possibility to go to "withdrawn" state.
More ideas welcome.
Comme
rror() called
LibGGI: _default_error() called
LibGGI: ggiExtensionAttach(0x836a7d0, 0) called
LibGGI: ggiExtensionAttach: ExtList now at 0x838a848 (1)
LibGGI: changed(0x836a7d0, 1) called for misc extension
LibGGI: changed() APILIST
LibGGI: Trying #0: display-dga-wmh()
LibGGI: Trying #1: gen
re perl ? Where ?
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
de
or something ...
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
I can map between event
> types such that I can use my stylus as a generic mouse replacement (i.e.
> map from valuators to positions), etc.
That is what filters (for common special cases) or LibGIC (universal
including an interactive configuration mechanism) are for.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
Stefan Seefeld <[EMAIL PROTECTED]> wrote:
> Andreas Beck wrote:
>
> > /* Deviceinfo stuff
> > */
> > int giiQueryDeviceInfo(gii_input_t inp, uint32 origin,
> > gii_cmddata_getdevinfo *info);
> > int giiQuery
> > Huh ? We do require perl ? Where ?
> automake requires perl...
Ah - o.k. - so for working from CVS sources we need it, but after running
autogen.sh all is well - right ? That's o.k. I'd say ...
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
der for it, which works great, but is a horrible
hack and uses a heuristic approach to get all that strange possible formats
and exceptions in an acceptable number of code lines.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
roposal is to add a synchronous* interface to GII to let users query
> device information. That would (IMO) even render the current command
> events obsolete.
If you find a good solution that will keep the stuff stream-transparent,
o.k. - otherwise I don't think it is worth the small gain.
The command events were created for exactly the purpose of keeping
everything transparent, even across processes and towards kernel drivers.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
s memory, i.e. as in a local address space ?
They shouldn't, or at least they should be implemented in streaming targets
to transparently get the needed info through the stream. Got to look at the
implementation to see if that happens.
Have fun,
Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
ses just to get that 0.1% more
functionality at the expense of 100% more complexity. If the above solution
fits your needs, that will give the 0.1% with only 2-3% extra complexity,
which I can stand :-).
Again please excuse if I annoyed you.
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
looked into this and found it to be very difficult, because of
around 100 callbacks from the X drivers back to X.
So for now using X drivers can be done as in "start X, start GGI app,
have it in a window" or in "start X, set GGI_DISPLAY, have the app start
using DGA
egant, though, as you'd need sprintf
or similar to construct the string.
Probably biting the bullet and adding another function like
giiGetInputAttributeByNumber(input,origin,number,char *attrname,int maxattrnamelen);
would be best.
Cu, Andy
> PS: and thanks to Brian for getting us ba
but rather of the
technical type, showing how easy one can do stuff like multi-display,
tiling, running clut-only apps on truecolor-only displays and
saving/replaying event streams usually does the trick
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
to set that
up from there or if it is the right thing to do.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
leration. Should be available from old (pre-Sourceforge)
snapshots.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
aid changes are only done to do something like
install-to-tmp, then package from there (avoiding to clutter system
directories), removing the leading temporary path, so that the final
install of the package will again be where the orginal build-time path
was - right ?
CU, Andy
--
= Andreas B
l.
I think he was talking about the addressing issue. See my other post.
I
> think there might be some code/ioctl to do this in newer Linux kernels,
Yes: mlock(const void *addr, size_t len)
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
ck and it returns sucess,
you should have nonswappable RAM. Don't know for Windows.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
ical RAM. So basically you always access both :-).
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
ied memory architectures, where
System RAM == VRAM.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
don't wonder too much, when it fails.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
and nice.
> Uhmm... When you buy a new graphic card, aren't you wondered why it
> requires a certain amount of system RAM ?
I usually consider that to be the same bullshit as on any application
software. They always say "PII-300 or better as minimum" or som
planar configuration, which
someone here told me could well be, as the card supports such a mode and
this mode has faster accels, so ...
It works for me in 16BPP modes, though. I'll recheck that as well later
tonight.
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
gic has no macro handling of its own, so it should
have been subbed.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
y
a screen->mem get operation and voila, I have hacked
the kernel, eventually bypassing security.
Even if the chip doesn't have get capabilities (which seem a strange thing),
you can still read the kernel image which compromises information like the
random pool or keys of crypted filesystems.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
possible to use a shared mapping.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
for some strange reason.
long long gave 64 bits
Cu, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
os with source rolled into a directory -
> possibly $(libdir)/ggi/demos or even $(datadir)/doc/libggi-demos or
> something like that.
Yeah. Agree. Demos aren't too useful in standard paths. I hate X for doing
that.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
does ?
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
s. To build libgii, the
> following patch is needed
Hmm - vgl is BSD-only AFAIK, so I wonder a bit. It may be a version issue
with VGL.
However, if the HALT and PDWN identifiers are in deed macros, the fix is
correct.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
looks for the primary config file.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
> Does patchlib only work for libggi or does it work for each lib?
If all libs do the path us ethe pathtag-stuff like LibGGI does, then yes.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
to be
much more picky than those of the SuSe distribution. Maybe there are more
(even pickier) compilers out there.
So I'd recommend that everyone does an errlog build and checks the warnings.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
a graphical shell , etc. ).
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
rk for
about any sane binary format, as it just chases for a strange tag, that is
implanted right before the confdir.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
ll us, that it
will cause a warning and maybe a problem with dumber compilers.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
to everyone who
was ever involved in the trigraph nonsense.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
uld be macroized or something.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
e use for polled devices.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
> > IDCT-transform engines and such?
> Don't know what IDCT stands for, but would like to
Inverse Discrete Cosine Transform. The base for decoding JPEG and
JPEG-related formats like Motion-JPEG and MPEG.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
se of
tmpnam in wrap.c and Makefile overriding of monitest commands.
Will test functionality right away ... hang on ... o.k. X target on XGGI als
demos go.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
t shouldn't be needed
anyway.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
> I propose to do that in _one_ toplevel-directory:
> libgii/packages/
> libgii/packages/debian/
> libgii/packages/rpm/
> libgii/packages/win32/
> libgii/packages/bsd/
> libgii/packages/solaris/
*nod* correct.
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
the "super-toplevel" ggi-core or even
the "super-super-toplevel" with all the modules.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
used by a
> particular distribution, but will work for a general system.
*nod* should work anywhere anyway. Most differences are in placement of
startup files and such, and this is a) converging and b) no problem for us,
as we have no daemons or similar.
CU, Andy
--
= Andreas Beck
k of this: You want to run GGI 2.0 stable, but be able to build and
> fully test GGI 2.1 development without clobbering your stable install.
No Problem: You just build and install with $prefix=~/local and set a few
config variables (LD_LIBRARY_PATH e.g.) so that these libs, includes etc.
are u
7;t think it would be a
good idea.
Maybe we could add something like
pragma AllowOverrideConfigfile
to the commandset to allow for developers to disable that security feature
on machines that only they have access to for their convenience.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
allenge, go for it.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
unning on a
windowing system.
However there was something like this there somewhen as well. However I
don't quite remember how it was called.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
ically speaking, it should only be white
if all pixels ever set there where white.
However as we have a discrete number of possible values, you might get white
by just adding a white layer often enough.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
> Anyone got a good reference on the cycle cost of function
> call overhead (compared by CPU family would be nice)? I try
> to figure it out myself, but am afraid that gcc is out-thinking me.
O.K. - I did a small test:
#include
#include
int bla=0;
void inc_bla(void) {
bla++;
}
#de
> > don't quite remember how it was called.
> libgwt ?
TNX - seems I'm getting old - my Alzheimer disease seems to get worse ;-).
But well - meeting lots of new people every day can be nice, too ;-).
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
, _ggi_db_get_new());
> @@ -366,7 +366,7 @@
> /* Only support frames when we can support linear access
>* and we have enough video memory. */
> if (!(vmi->flags & CAPABLE_LINEAR)
> - && (vmi->memory < (vmi->bytesperpixel * tm->virt.x *
> + || (vmi->memory < (vmi->bytesperpixel * tm->virt.x *
> tm->virt.y * tm->frames)))
> {
> tm->frames = 1;
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
le to render into an
application internal buffer with Macros (!) and Pointers to avoid the
call overhead and then blit to screen or to use the LibGGI DirectBuffers.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
the long run using LibBlt is the way to go.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
sequence. Better is:
ggiWaitRayPos(vis, &x, &y);
draw_whatever();
ggiFlush();
This ensures the drawing takes place while the ray is retracing. Other
method depends on being inside a tight loop.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
er is waiting for retrace. If you draw
too long before checking for retrace, flicker will occur.
Hardware-assistance will automatically switch frames when retrace happens
and you can later query that the change happened.
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
t; }
Moreover you should set a mode before drawing:
> ggiFillscreen(vis);
> ggiPutPixel(vis, 0, 0, blue);
and use
int ggiKbhit(ggi_visual_t vis);
int ggiGetc(ggi_visual_t vis);
instead of:
> getchar();
Cu, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
Christoph Egger <[EMAIL PROTECTED]> wrote:
> Andy: Which version of libgii and libggi are you running on your Solaris
> machines? As you know, we have a new building environment.
A really antique one ... I'll see if I can get around to testing a fresh
install.
CU, Andy
-
bled explicitly.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
n:901.
** These are from the 5 consecutive ones later (inputs are still
** unjoined there. Only the last finding is correct, which
** seems to be proved by the "verfiy" lines.
However that seems to indicate a big bug somewhere, as
1. giiQueryDeviceInfoByNumber should work on any
hout having to add any more API
> functions to LibGII itself.
Apropos origins - did noone read my bug report about the
"querying-for-inputs" problem ?
I'd like to have confirmed that it exists and is not only a quirk of my
program or my strange setup before diving into the code
and have never
experienced that problem.
> P.S.- Is there any documentation on these demo.s ?
Yes - in the source, as they are primarily intended to be sample programs,
which is why most of them aren't installed by default.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
00 FF 00 00 => R=00,G=00,B=FF => blue
App: blue : 00 00 FF 00 => R=00,G=FF,B=00 => green
App: white: FF FF FF 00 => R=00,G=FF,B=FF => light cyan
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
stbyname -- referenced in the text segment of
> libtele.o
Simplest solution:
Unless you absolutely need the teleserver/-target, just disable the whole
tele target.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
ute.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
he physical
screen borders.
Cu, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
Ooops - seems like I opened a can of worms here ...
The fix does away with teh segfault in giiSplitInput, but it seems to leave
the lock of at leats one of the remaining inputs locked or undefined.
Will investigate further.
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
Andreas Beck <[EMAIL PROTECTED]> wrote:
> Ooops - seems like I opened a can of worms here ...
Second try:
Patch as before plus:
Obviosly we should not bail out even on a bogus request with
locks retained:
@@ -843,14 +849,13 @@
individual origin. */
> * BUGFIX: Make devinfo related structures exist per-input (Eric)
> - Verify, if devinfo related structures per-input BUGFIX works.
Make that * - it works for me (TM)
> * BUGFIX: Make libgii working in a multi-threaded environment (Andreas Beck)
Actually libgii did work there, but so
e it spin, select the active side etc.
> and also if the user selects one of the cube-sides then can they interface
> with the running application?
Yes.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
mouse control.
Regarding being able to click a side, this is of course a possible
extension, though a nontrivial one, due to the transparency.
BTW: There is also "auto"-mode, which will automatically select the visual
for input that is "closest" to the viewer.
CU
gt; Right?
Right - just that I'd prefer to use up and down instead of left/right.
In order to enable SetOrigin for vesafb, you need to pass it the "ypan"
option - see /usr/src/linux/Documentation/fb/vesafb.txt for more
information.
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
then I would prefer
> the first one, because pop3 doesn't encrypt the own password.
Ack. Forwarding would be good for me as well. I already poll around 10 pop
boxes ...
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
to
both libs WRT to multi-visual and repeated-open-close type applications.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
y = AF_UNIX;
> - strcpy(dest_un.sun_path, addr);
> + strncpy(dest_un.sun_path, addr, strlen(addr)+1);
WHAT ? No - that one would limit by the _source_ size. Unless it is
explicitly made sure that dest_un.sun_path is large enough to handle
strlen(addr)+1 (in which case the strcpy would do), this is the wrong thing
to do. It might quieten that strange scanner software, but it doesn't do
anything good. It's a NOP.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
rminate the string after every usage of snprintf using something
like
#define TERMINATE_ARRAY(x) x[sizeof(x)-1]='\0'
#define TERMINATE_POINTER(x,len) x[len-1]='\0'
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
> > That's the point. I cannot derive from that, if snprintf will
> > terminate the string, if an overflow occurs, without leaving a little
> > doubt.
> So, the question is, what does vsnprintf() ?
It seems to do the right thing. However I'd vote for testing it at
configure time and complain if
ed to the ggi-project.org domain?
Should we register something else?
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
sed for hogging simpler instead of even
supporting that practise by referring to domain auction sites
and similar.
Just my personal war .-),
Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
that
> I guess we need to take over their building with a commando
> or something...
O.K. - send GPS coords. Will coordinate the thermo-nuklear backup.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
ble and the closest thing that can do less if not" is the nicest
Interface I can think of.
As the rules by which these "_more_" decisions are taken are clearly
defined, other modes that would also do can easily be probed.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
PI anymore apart from fixing
obvious bugs that need an API change to fix.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
1 - 100 of 662 matches
Mail list logo
