Maybe I should have described the patch a little more, even though it's
rather short.
Initialization
--
Define an array _lastKey[] in which every physical key is mapped to a
keySym. All entries are initialized to -1, which means that the key
is not pressed. Array size is 256 on X11
Hi,
Added the unmapped/modified key to the GUIEventAdapter is something
we've discussed in the past.
That would allow applications to work around that OSG *bug*. But IMHO
that's clearly a bug.
The unmodifed would have to be assigned in addition to the existing
modified key, as just
Here's another illustration of what the patch does. The first part
is what the added code in KeyPress does, the second part is what
the code in KeyRelease does.
press '3' (with autorepetition), press shift, release '3', release 'shift':
key: 51, shift: 0, pressed: 1
key: 51, shift: 0,
* Robert Osfield -- Thursday 04 June 2009:
I'm in two minds if I'd would classify this issue as a bug, and I'm in
two minds about your suggested remedy. The code is it stands right
now doesn't enforce a matching of presses and releases, it just the
way it works. It's a bug if your assume
Hey,
* Mathias Fröhlich -- Thursday 04 June 2009:
May be we need to track these up/down event pairs in *flightgear*.
We can't ATM, because we don't have the keycodes! That's why I started the
thread in the first place! And my assumption was that it's better fixed
once in OSG, than in every
At the moment there's no guarantee that for a key that triggered a key-press
event before there will ever be the matching key-release event later. This
is a problem for applications like FlightGear: here pressing the b-key, for
example, applies the brakes on the landing gear until the key is
* Robert Osfield -- Monday 01 June 2009:
Clearly it's not [now] badly broken so we'll have to find another route.
I do some investigation at my end.
Here's how to deal with it (once SVN is up again :-):
$ svn diff -r10268:10269|patch -p0 -R
Now the question is: what's up with russian
* Robert Osfield -- Monday 01 June 2009:
I've refactored the adaptKey method to use XLookupString in a bit more
thorough way to than it did before, it ensures that osgkeyboard works
fine on my Linux box with UK keyboard. Could you try this?
Umm ... did you try osgkeyboard this time? This
* Robert Osfield -- Monday 01 June 2009:
see if things are now working correctly in osgkeyboard
Nope.
Ctrl-a returns 0004-0061 again (an 'a'), instead of 0004-0001,
and Delete returns -.
m.
___
osg-users mailing list
Hi,
* Robert Osfield -- Monday 01 June 2009:
The Delete returning a osgGA::GUIEventAdapter::KEY_Delete is appropriate
though.
Whoops, sorry. Looked suspicious, and there's no way to test that in
osgkeyboard.
Have yet to link FlightGear with the new version, but ...
Could you try the
Passed the FlightGear test without problems.
m.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
* Robert Osfield -- Monday 01 June 2009:
Could you both do testing to check that things now
work across the various locale combinations and applications.
My keyboard doesn't have a keypad, so I can only test the other keys.
(I'll try to find someone with keypad, but no promise. :-)
m.
* Melchior FRANZ -- Monday 01 June 2009:
My keyboard doesn't have a keypad, so I can only test the other keys.
... but everything else worked. And we'll soon find out if there are
still keypad problems. The current solution is already infinitely
better than what is in SVN/HEAD, so I'd commit
* Robert Osfield -- Tuesday 10 February 2009:
Any chance that FlightFear is modifying the
ParticleSystem/ParticleSystemUpdate within the cull traversal?
No idea. Have to check with one of our osg experts.
What happens we you try differnt threading models like
CullDrawThreadPerContext,
Hey,
* Mathias Fröhlich -- Tuesday 10 February 2009:
I can see no connection between the helgrind warning and a segfault.
What helgrind tells you, is that there is a possible dealock situation
that can potentially happen due to that inverted lock order.
But the effect of a deadlock is a
Hi,
* Robert Osfield -- Monday 09 February 2009:
Do you agree/disagree that we are ready to tag?
you'll probably not be surprised if I say: I disagree. :-)
I had reported a segfault and the diagnose output of valgrind/helgrind,
which affirms that there is a threading bug (maybe in the
* Robert Osfield -- Monday 09 February 2009:
The segfault I saw with your example was because the example was
broken as the viewer wasn't ref counted, this wasn't an OSG bug.
But valgrind/helgrind reported a bug in *OSG*, in the same
area where FlightGear crashes. I didn't let it run over
* Robert Osfield -- Monday 09 February 2009:
I've just run valgrind and it generates a number of what it thinks are
errors,
You are aware that I didn't use valgrind's standard tool mecheck,
but its threading checker helgrind?
$ valgrind --tool=helgrind ./osgparticleeffects
* Alberto Luaces -- Monday 09 February 2009:
Did you know that you can also attach a debugger
Yes, of course. But the helgrind output already contained
*exact* line numbers where it found the locking order to
be wrong. There wasn't much point in staring at the lines.
Those by themselves aren't
Hi,
* Robert Osfield -- Monday 09 February 2009:
In my testing here I'm using the tool=helgrind
Oh, sorry then.
3rd party debugging tools aren't infaluable. The can and do produce
false positives.
Yes, of course. But if I get a segfault in FlightGear which gdb
traces back to some lines
* Robert Osfield -- Monday 09 February 2009:
How easy is it to build FlightGear these days?
Shouldn't be too hard for you, as you probably have a lot of the
necessary components installed already (osg, libpng, libjpg, openal,
alut etc.)
So all you'll need is a decent scene graph lib:;-)
* Robert Osfield -- Monday 09 February 2009:
Thanks for the instructions on getting flight gear I'll have bash.
You'd also need the data. And ~2GB free disk space, though you could
leave most aircraft away, which saves a lot:
$ cvs -d
* Robert Osfield -- Monday 09 February 2009:
An svn update to the OSG-2.8 branch will get you these changes.
OK. I updated and recompiled, and will now test fgfs intensively.
One evening won't be enough to confirm that the problem is fixed,
but the fact that helgrind no longer complains is a
* Robert Osfield -- Monday 09 February 2009:
An svn update to the OSG-2.8 branch will get you these changes.
Tried with that ...
Changing to mutex solves the valigrind/helgrind warnings when you run
osgparticleeffects in SingleThreaded.
Confirmed. However, in fgfs I got again a segfault
Hi,
* Robert Osfield -- Friday 06 February 2009:
The code in osgParticle::ParticleSystemUpdater has changed very little
over the past two years, so I think it's unlikely to be a specific
problem with osgParticle in OSG2.8/svn/trunk,
I didn't claim that it's a particle bug -- just that it
* Melchior FRANZ -- Tuesday 03 February 2009:
Just for the record: I've had several segfaults in OSG's
particle code (threading related) since I updated a few
days ago. I'll post a backtrace when I run into it again.
Linux 2.6.28.3, P4/32bit, gcc 4.3.1, osg r9631, FlightGear.
(The warnings
Just for the record: I've had several segfaults in OSG's
particle code (threading related) since I updated a few
days ago. I'll post a backtrace when I run into it again.
m.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
* Robert Osfield -- Thursday 13 November 2008:
pkg-config poppler-glib --modversion
0.6
$ pkg-config poppler-glib --modversion
0.10.0
pkg-config poppler-glib --libs
-lpoppler-glib -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0
-lfontconfig -lXext -lXrender -lXinerama -lXi
[undefined reference to `gdk_pixbuf_new_from_data']
osgpdf is the only osg app that isn't linked correctly with
LDFLAGS=-Wl,--as-needed. That's apparently globally on on
some systems like Gentoo, and also on my non-Gentoo system.
The problem is usually that libraries/objects aren't listed
in the
* Melchior FRANZ -- Thursday 13 November 2008:
I couldn't yet figure out how to get the full gcc command
line.)
OK, I figured it out. Will investigate ...
m.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http
* Jean-Sébastien Guay -- Wednesday 12 November 2008:
One thing, I think you need to move the test for Poppler from the
examples/osgpdf/CMakeLists.txt to the base CMakeLists.txt, otherwise
POPPLER_FOUND can never be true when adding the osgpdf example in
examples/CMakeLists.txt (or at least,
* Robert Osfield -- Wednesday 12 November 2008:
fix to Poppler check now checked in.
Now cmake tries to compile osgpdf, and fails:
/usr/local/lib/libpoppler-glib.so: undefined reference to
`gdk_pixbuf_new_from_data'
/usr/local/lib/libpoppler-glib.so: undefined reference to
* Robert Osfield -- Friday 24 October 2008:
But it doesn't really say anything about the how the texture wrap
modes map to this, if at all.
I can't say that either, but the current situation is bad. Because
'texrep 1 1' is default anyway (according to spec and reference
implementation) AC3D
* Robert Osfield -- Wednesday 01 October 2008:
Is there are particular combination of usage that reveals
the bug?
No. Just happened sometimes during FlightGear startup. I haven't
seen it now since a few days. I hadn't invested much time in
finding the cause, as I was busy with other stuff, and
* Melchior FRANZ -- Saturday 27 September 2008:
yes. Meanwhile I switched back to OSG revision 8779 and
the problem is gone.
No, just got it again with that revision. So the bug is very
likely in FlightGear, as I don't think I had problems with
revisions around that time.
m
As demanded by Robert, I repost an extended bug report that went
to osg-submissions first. This segfault happened before Lionel's
fix for that same function, and it still happens afterwards, using
revision 8944:
OS: Linux 2.6.25.2 (i86/Intel P4/32bit)
gcc: (SUSE Linux) 4.3.1 20080507
* Robert Osfield -- Friday 26 September 2008:
Have you tested flight gear before on your machine?
yes (for years)
Is this crash a new problem that has recently arisen?
yes. Meanwhile I switched back to OSG revision 8779 and
the problem is gone.
Do you compile the OSG and FlightGear from
* Melchior FRANZ -- Friday 20 June 2008:
$OSG/include/OpenThreads/Atomic:140: error: \
‘oldPtr’ was not declared in this scope
OK, so this should be ptrOld now? As in:
--- include/OpenThreads/Atomic (revision 8468)
+++ include/OpenThreads/Atomic (working copy)
@@ -132,12 +132,12
* Mathias Fröhlich -- Friday 20 June 2008:
[Performing Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS - Failed]
If you specify any
-march=whatevernewertargettocompilefor
to gcc the builtin is inlined with something usable.
I was using -march=pentium4 already, so it should have worked?
m.
* Gino van den Bergen -- Wednesday 05 March 2008:
1) Full DOS paths are now correctly opened by OpenVRML. A URL containing
a DOS path should be file:///C:data/blah rather than file://C:data/blah.
AFAIK the first is right and the second is wrong. I don't know how
the C: is handled (as a dir or
* Jean-Sébastien Guay -- Wednesday 05 March 2008:
Can you quote some documentation for that?
RFC2396
Just type the lines in the address field of a standards compliant
web browser (which probably rules out MSIE; try Firefox :-) with
a file path that exists on your machine.line with a file path
Considering that again ...
* Melchior FRANZ -- Thursday 28 February 2008:
strip absolute paths (beginning with '/' or '\\' or matching ^[A-Za-z]:[\\/]
the ^\\ case is very likely superfluous, and the rule for DOS
paths can be simplified to ^[:alpha:]:. New patch attached.
m.
// 30 Oct 2002
-submissions, as the instructions say.
This here was only for people to test and review before submission.
The real submission was this (and there's nothing else pending):
Re: osgViewer/X11: fix for stuck-keys bug
Date: Fri, 22 Feb 2008 23:31:31 +0100
From: Melchior FRANZ [EMAIL PROTECTED
* Robert Osfield -- Monday 25 February 2008:
although caps lock is currently getting out of sync.
My keyboard doesn't have a caps lock key. But I'll plug another
in and check.
One other item that needs resolving is the warning:
* Melchior FRANZ -- Friday 22 February 2008:
Here's a new version with the following changes made:
- be a bit more pedantic about modifier settings for
artificially pressed/released keys
- fix a compiler warning
- simplification minor improvements
attached:
./src/osgViewer
* Robert Osfield -- Monday 25 February 2008:
/home/robert/OpenSceneGraph/src/osgViewer/GraphicsWindowX11.cpp:1310:
warning: converting to 'Time' from 'double'
Which relates to:
event.time = time;
This can simple be changed to
event.time = 0;
We only fill an XKeyboardEvent here
* Robert Osfield -- Monday 25 February 2008:
I was wondering about just setting time to 0, the X11 headers mention
that 0 represents the current time.
The XKeyEvent is only filled out for XLookupString, which in turn
only looks at the display, keycode and the modifier mask for
translating the
* Melchior FRANZ -- Monday 25 February 2008:
Err ... I told you to take the files from the followup message in
that thread, not the one from the first message.
Ah, sorry. You did that. :-/
I'll check the code again.
m.
___
osg-users mailing list
I've meanwhile submitted a fix. In case someone wants to try
it and is not subscribed to osg-submissions, it's available
here:
http://members.aon.at/mfranz/X11-kbd-fix.diff.bz2 [2.6 kB]
This patch does additionally have a compilation warning fixed
that didn't occur on my system, and it
Attached is my suggested fix for the keyboard bug. The
behavior should be the same as before, except when losing
the focus (FocusOut, LeaveNotify) all keys are released
(normal keys first, modifiers at last), and on re-entering
(KeymapNotify) pressed (modifiers first, other keys afterwards).
I'll
* till busch -- Thursday 07 February 2008:
ulrich hertlein said something about KeymapNotify which is
generated after every EnterNotify and FocusIn. something
like this might be a better place?
I never use alt+tab, so I didn't notice. Don't know yet about
KeymapNotify, but we don't want to
Thanks to all who replied. I've now written a cleaner fix.
The focus on modifiers was silly. After we lose all releases
on a window hide event, not only modifier releases, we also
have to fake-release all of them. What made the most sense
to me was to maintain a keyStateMap which keeps track of
There's a problem with the keyboard support on X11. It's really
caused by the way X works, and SDL or glut are said to struggle
with it as well. I haven't seen the problem there, though, so
they probably found a way to work around it.
To reproduce start the osgkeyboard example, press a few
* Jean-Sébastien Guay -- Tuesday 05 February 2008:
For reference, the same thing happens on Windows,
Oh, didn't know that.
Not sure if OSG should try to work around it or not...
Well, but it's annoying as hell, and my computer is not
supposed to annoy me. :-)
And again: I never saw that
* Bradford, Chase -- Tuesday 05 February 2008:
On the Windows side, we could explicitly poll a modifier key's state
before sending an event off to the EventQueue, without relying on
KEYUP/KEYDOWN synchronization. However, doing something like that
would cause inconsistencies between the
Hi,
* Robert Osfield -- Thursday 04 October 2007:
As David mentioned there are the initial configuration files now
checked into OpenSceneGraph-Data SVN.
the license of the files in OpenSceneGraph-Data is very restrictive,
which is rather unusual for an F/OSS project. One can't even derive
his
* Robert Osfield -- Thursday 04 October 2007:
The non commercial clause is there due to some of the files, most will
actually be OK to copy and use of commercial use but to be rather safe
than sorry the README is conservative.
Actually OK isn't really enough, when the license literally
forbids
57 matches
Mail list logo
