Re: [osg-users] [RFC] osgViewer: solution for omitted key release events
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 (of which the first 8 entries
are unused).
On my US-keyboard key '3'/'#' key has hardware keycode 12. So, most
of the time _lastKey[12] will be one of -1 (not pressed), '3', or '#'.
Key press event
---
if (_lastKey[keycode] != -1) // press event for an already
pressed key?
// ... that means it's autorepeating
if (_lastKey[keycode] != keySym) // but the keySym suddenly changed,
so a
// modifier must have changed
(shift, ...)
release(_lastKey[keycode]); // then send an artificial release
for the
// former keySym, before continuing
with
// the new
_lastKey[keycode] = keySym; // store the new keySym for that key
Key release event
-
if (_lastKey[keycode] != -1) {// release key that isn't pressed?
Shouldn't
// happen, but just to be safe ...
keySym = _lastKey[keycode]; // make sure to release the *right*
keySym,
// the one for which the key press
was reported
_lastKey[keycode] = -1; // and mark the physical key
released
}
m.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [RFC] osgViewer: solution for omitted key release events
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 dropping the mapping would break exisiting applications, The patch would properly release keys, that would otherwise remain in (logically) stuck position. I don't see how this could break an application. One that assumed that OSG will not report all key releases properly? Most applications probably don't care about key releases at all, but those that do will probably work *better* if the releases are reliable. ;-) Reading your email I could pick out exactly what you were doing, but it sounded like you were duplicated events which doesn't does appropriate as again this would break applications. No, I don't duplicate anything. I add what OSG occasionally fails to do. I've sent another explanation just a few minutes ago. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [RFC] osgViewer: solution for omitted key release events
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, pressed: 1
key: 51, shift: 0, pressed: 1
key: 51, shift: 1, pressed: 0 this release event *added* by the
key: 35, shift: 1, pressed: 1 patch, otherwise 51=='3' would never
key: 35, shift: 1, pressed: 1 be released
key: 35, shift: 1, pressed: 1
key: 35, shift: 1, pressed: 0
like above, but typing the sequence faster:
key: 51, shift: 0, pressed: 1
key: 51, shift: 1, pressed: 0 this changed from 35 ('#') to 51 ('3')
by the patch, otherwise 51 would never
be released, but 35 (which wasn't even
reported pressed before)
m.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [RFC] osgViewer: solution for omitted key release events
* 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 that it does match.
Yes, and that's why applications can't do things for the duration of
a keypress. Consider the FightGear case again: pressing the SPACE
bar activates VoIP communication. If one releases the SPACE bar,
the microphone should be muted again. At the moment I can't rely
on that. There may never be a release event, because pressing the
Ctrl-key might modify 32 to 0. (Yes, we are hacking around this
unreliability, but that really only works for letters, as one can
assume that 'a', 'A', and 1 (Ctrl-a) are on the same physical key.
We can't make any assumptions for other keys.)
Making the physcial key number available in the event structure would
allow us to fix our problem in FlightGear, though I think the bug
is in OSG and should be fixed there.
Making them match does require inserting artificial events that the
the person at the keyboard has never instigated directly,
Yes, but no unreasonable events. Actually, these are the events that
anyone would expect. And it's not like OSG wouldn't add other artificial
keypress/release events already. Remember my last keyboard patches?
If the window loses focus (e.g. by desktop switching), then all keys
are artificially released. If it regains focus, they are all artificially
pressed again. And that wasn't a convenience thing -- it solved another
stuck-keys problem (because while the window didn't have focus, modifiers
could be changed outside, and the OSG app wouldn't notice).
if you press
an 'a' key, then press shift to 'A', then release the 'A' then that is
the sequence events. What you haven't done is press 'a', release 'a',
pressed 'A' then release 'A', which is what you are saying should
happen be resented in events passed back from the OSG - this in itself
could be considered a bug.
The problem starts where you drop information about what's *really*
going on (i.e. the physical key number), and replace it with keySym.
By dropping essential information, you take responsibility for the
sanity of what you pass. Keys that are undetectably, logically stuck
for the client are certainly not a feature. At least not one that
you'd want to mention in your ads. ;-) But I see your point ...
I don't know what the solution should be yet, but I suspect it'll
require some more information passed back via GUIEventAdapter, and
make it easier to track unmodified key events. Whatever solution we
go for it'll have to work identically across all platforms.
Adding the physical key number to the key events sounds like a good
idea, but it's a two-edged sword: OSG client code that relies on
that can easily make questionable assumptions about the keyboard
hardware and thus stop working on other input devices. (But then again,
assuming that '3' is next to '4' isn't any better, and we don't have
problems with that. :-)
But doing only that (without my patch) would require all clients
(that care about proper releases) to re-invent the fix. Adding the
fix to all platforms and adding a flag that says this event is
artificial (was added by OSG), ignore it if you aren't into this
sort of stuff might indeed be desirable.
m.
PS: in the patch I made a stupid untested last-minute change that
causes compiler warnings about signed/unsigned. Should have been:
for (unsigned int i = 0; i sizeof(_lastKey) / sizeof(int); i++)
(But again, the patch was only a simplified version to show the
solution, and not meant to be applied.)
PPS: this was badly worded:
if (_lastKey[keycode] != -1) { // release key that isn't pressed?
Shouldn't
// happen, but just to be safe ...
the comment should have been:
// if the key was actually reported pressed
// before (which should really always be
the
// case, but better be safe)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [RFC] osgViewer: solution for omitted key release events
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 single application with the same issue. But
I don't insist, and not only because that wouldn't work. ;-)
This key issue is why we have this gem in FlightGear's FGEventHandler.cxx:
// Release the letter key, for which the key press was reported. This
// is to deal with Ctrl-press - a-press - Ctrl-release - a-release
// correctly.
if (key = 0 key 128) {
if (modifiers KEYMOD_RELEASED) {
key = release_keys[key];
} else {
release_keys[key] = key;
if (key = 1 key = 26) {
release_keys[key + '@'] = key;
release_keys[key + '`'] = key;
} else if (key = 'A' key = 'Z') {
release_keys[key - '@'] = key;
release_keys[tolower(key)] = key;
} else if (key = 'a' key = 'z') {
release_keys[key - '`'] = key;
release_keys[toupper(key)] = key;
}
}
}
But that fixes the problem only for letter keys, for which, as I've said
already, the workaround is quite simple. It's impossible for all other
keys. There's another one that's even uglier in multikey.nas:
if (cmd == and key.getValue() == `;`) # FIXME hack around kbd bug
key.setValue(`:`);
This considers that a ':' might never be released as ':', but as ';'.
*On US-layout!* (Screw all the rest, I say. :-)
... if an application needs these synthetic events, exactly this application
should synthesize these events?
Well, if additional (we have some already!) artifical events are considered
undesirable, sure. Then we need the keycode in the key event structure.
Either is fine with me, really. At the moment it's broken and *unfixable*
in FlightGear.
m.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [RFC] osgViewer: solution for omitted key release events
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 reported
released. If there's never a release, then the brakes remain stuck, until
one pressed/released b again. But how could the release event possibly get
lost? Consider this:
1. b down - 'b' press event
2. Shift down - shift modifier set
3. b up - 'B' release event (but 'B' was never reported pressed!)
4. Shift up - shift modifier unset
Well, letters aren't really a *big* problem. We hack around that by checking
for an a-release if maybe 'A' or Ctrl-a was reported pressed before, or for
an A-release if maybe 'a' or Ctrl-a ... etc.
But what about this case:
1. \ down - '\' press event
2. Shift down
3. \ up - '|' release event -- '\' remains stuck!!
4. Shift up
We can't hack around that, because it depends on the keyboard layout whether
\ and | are on the same key. This information is lost for the OSG client and
can't be retrieved in a cross-platform way. That's OSG's job.
One way to fix that would be to store all reported symbols for press events per
physical key, and to make sure that the same symbol will be reported for the
release, even if that means to inject an artificial release. This works here
in my local build. (The attached patch is not meant to be applied -- I'd make
some more cleanup before. All usage of _keyMap could then be removed, too.)
Any comments on that? Windows and Mac maintainers would have to implement the
same solution, which is the main reason for the RFC. Otherwise I would just
have submitted the patch. And I can only remove the hack in FlightGear, once
all platforms work correctly.
(Should EventTime for the generated release event differ from the press event,
e.g. by subtracting a very small time?)
m.
Index: include/osgViewer/api/X11/GraphicsWindowX11
===
--- include/osgViewer/api/X11/GraphicsWindowX11 (revision 10305)
+++ include/osgViewer/api/X11/GraphicsWindowX11 (working copy)
@@ -52,6 +52,8 @@
{
_traits = traits;
memset(_keyMap, 0, 32);
+for (int i = 0; i sizeof(_lastKey) / sizeof(int); i++)
+_lastKey[i] = -1;
init();
@@ -195,6 +197,7 @@
int _modifierState;
int _numLockMask;
+int _lastKey[256];
char_keyMap[32];
std::mapMouseCursor,Cursor _mouseCursorMap;
};
Index: src/osgViewer/GraphicsWindowX11.cpp
===
--- src/osgViewer/GraphicsWindowX11.cpp (revision 10305)
+++ src/osgViewer/GraphicsWindowX11.cpp (working copy)
@@ -1246,10 +1246,16 @@
eventTime = baseTime + static_castdouble(relativeTime)*0.001;
_modifierState = ev.xkey.state;
-keyMapSetKey(_keyMap, ev.xkey.keycode);
int keySymbol = 0;
adaptKey(ev.xkey, keySymbol);
+int lastKey = _lastKey[ev.xkey.keycode];
+if (lastKey != -1 lastKey != keySymbol)
+getEventQueue()-keyRelease(lastKey, eventTime);
+
+_lastKey[ev.xkey.keycode] = keySymbol;
+
+keyMapSetKey(_keyMap, ev.xkey.keycode);
getEventQueue()-keyPress(keySymbol, eventTime);
break;
}
@@ -1280,6 +1286,11 @@
keyMapClearKey(_keyMap, ev.xkey.keycode);
int keySymbol = 0;
adaptKey(ev.xkey, keySymbol);
+
+if (_lastKey[ev.xkey.keycode] != -1) {
+keySymbol = _lastKey[ev.xkey.keycode];
+_lastKey[ev.xkey.keycode] = -1;
+}
getEventQueue()-keyRelease(keySymbol, eventTime);
break;
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux
* 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 keyboards? Are we really to assume that X can't handle them, unlike any other layout? We were using XLookupString(), and that should do the right thing for any keyboard, no? Could Maxim's problem stem from a local misconfiguration at his machine? Any other Russian users out there who could shed a light on the issue? Maybe GraphicsWindowX11cpp should only change it's former (right) behaviour if a key returns 0, as it was in Maxim's case? (0 is a valid value, though. You get it with Ctrl-Space.) m ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux
* 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 patch swallows Backspace. Frankly, I find all these recent keyboard hacks rather worrying. I'd really like Maxim to provide more info about the problem first (as you suggested in your last post). Better let the keyboard as it was for now. This could be a broken X server on his side (devel version or something), or a broken setup or whatever. I can't believe that he's the only one with a russian keyboard. Looks like everyone elses works just fine. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux
* 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux
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 attached GraphicsWindowX11.cpp. ... so far it looks good! That's with an US-keyboard. Now trying FlightGear ... m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux
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
Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux
* 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. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux
* 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. Thanks for the fix! m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
* 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, SingleThreaded and DrawThreadPerContext? Will try later. For now I've recompiled everything with -O0, and have run fgfs for hours, without crash. I don't really think that the slightly changed compiler/linker flags have removed the cause for the segfault, but the now much lower frame rate has probably changed the timing such that it's now less likely to occur. I'll continue the tests, and will give some more useful info about my next crash (if any). Of coursem, I agree that there was no more reason to delay the 2.8 release. :-) m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
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 hanging application or thread or something like that - not a segfault ... Yes, that's what I even assumed. I was surprised to get a segfault on the lock. But then again, a segfault on the lock, a reported threading error there, ... and lack of knowledge about threading. ;-) * Mathias Fröhlich -- Tuesday 10 February 2009: For the nvidia drivers on linux you need the --smc-check=all valgrind argument. The thing appears to be that the nvidia drivers dynamically build code on the cpu that is not tracked correctly by valgrind without that argument Oh, that's news to me. Thanks a lot. Will try. When I tried to explore the core dump, I didn't get far. I had built with optimization, and several variables were not accessible. Will rebuild everything with -O0 today and re-run valgrind --smc-check=all. Good luck ... Thanks. :-) m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
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 particles code?). It's very likely that this is exactly the bug which causes the segfaults. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
* 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 FlightGEar, but over osgparticleeffects. No broken example involved here. (Unless osgparticleeffects is broken, too, of course. :-) I haven't had a chance to investigate the valgrind report though, have you had a chance? I'm sorry. I know that patches are more welcomed than bug reports. But it would probably have taken me many hours, if not days, to understand how the code is supposed to work, before I could even start to search for the bug. Time that I better spend on (OSS) projects where I know the code (and that need as much bugfixing). m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
* 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 ==31276== Thread #1: lock order 0x58F499C before 0x58F494C violated ==31276== Thread #1: lock order 0x58F6A9C before 0x58F6AEC violated OpenThreads and osgParticle have not changed in any substantial way for quite some while, so these errors have likely been there for a long time. Sure, it may well be that the broken threading is old and has caused segfaults before. :-P Do you get a crash in osgparticleeffects? If so how quickly? None. But OSG is a library. Whether examples crash or not is IMHO not really relevant, *if* there are bugs in the lib. Sure, we can just assume/pretend that helgrind is buggy and osg is bugfree. ;-) m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
* 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 the bug, just the order in which they are called. And for that I would have needed a lot more (or any ;-) insight into the osg workings. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
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 of code in OSG, and then helgrind points out a bug in pretty much exactly the same lines, then my first assumption is not that helgrind is buggy. And helgrind's report was IMHO very precise. How much we can rely upon valgraind/helgrind is not something I can vouch for as this is the first time I'm attempted to use tool=helgrind. Yeah, same here. I'm a total helgrind newbie. But still: segfault and threading bug reported by two independent tools in the same code. But before I annoy the last person here, I stop bitching. Just release OSG as it is. Maybe gdb and helgrind and FlightGear get fixed and the problem goes away all by itself. ;-) m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
* 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:;-) $ svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib We still use some parts of that -- networking, joystick, GUI. Then you need SimGear: $ cvs -d :pserver:cvsgu...@cvs.simgear.org:/var/cvs/SimGear-0.3 login CVS passwd: guest $ cvs -d :pserver:cvsgu...@cvs.simgear.org:/var/cvs/SimGear-0.3 co source And FlightGear itself: $ cvs -d :pserver:cvsgu...@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login CVS passwd: guest $ cvs -d :pserver:cvsgu...@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co source It's the usual ./autogen.sh ./configure make sudo make install everywhere, IIRC. At my end I do have the helgrind output that suggests a problem, but I don't have a crash, [...] I cannot reproduce the crash every time either. Happens once in a while, but *if* it happens, then the origin is always the same. There's nothing fuzzy about it. I am looking into ways of refactoring this class to fix the potential problems. That sounds much too dangerous shortly before a release. I'd rather look into that afterwards. Crashes aren't nice, but messing up a lib before a release is far worse. :-) Are you around for the rest of the day? Can I push a testing question of new code in your direction? Yes, and sure. But note that I can't reproduce it with every fgfs run. I'd have to run fgfs dozens of times and hope that it segfaults. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
* 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 :pserver:cvsgu...@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login CVS passwd: guest $ cvs -d :pserver:cvsgu...@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co data I wrote that I can't reliably reproduce, but what I can do is put lots of particle-using aircraft in the scenery, which should increase the crashiness. Will try that now ... m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
* 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 good sign. I'll continue testing ... you can see me on our live-multiplayer map as cptf: http://mpmap01.flightgear.org/ Thanks for your efforts so far! m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
* 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 with particles
and threading ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb67d16f0 (LWP 32467)]
osgParticle::ParticleSystemUpdater::traverse (this=0x96be668, n...@0x9843150)
at /home/m/fgfs/osg/include/OpenThreads/ScopedLock:31
31 explicit ScopedLock(M m):m_lock(m) {m_lock.lock();}
Can't say more, as I had to throw the core file away (don't ask :-).
Now I'm helgrinding fgfs+osg, and after that I'll make another
fgfs run and will then explore the next core dump ...
m.
PS: the ParticleSystemUpdater is a beast!
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] segfault: particle/threads
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 regularly happens in the particle code. The bt implies that it's a threading bug. Also try the OSG examples with particle systems such as osgparticleeffects, osgparticle and osgcatch. I'm a lazy bum and just let valgrind's threading debugger helgrind run over osgparticleeffects. Result attached (from osg r9676). Summary: $ valgrind --tool=helgrind ./osgparticleeffects ==31276== Helgrind, a thread error detector. [...] ==31276== Thread #1: lock order 0x58F499C before 0x58F494C violated [...] ==31276== Thread #1: lock order 0x58F6A9C before 0x58F6AEC violated [...] ==31276== ERROR SUMMARY: 512 errors from 2 contexts (suppressed: 0 from 0) m. ==31276== Helgrind, a thread error detector. ==31276== Copyright (C) 2007-2008, and GNU GPL'd, by OpenWorks LLP et al. ==31276== Using LibVEX rev 1883, a library for dynamic binary translation. ==31276== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==31276== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework. ==31276== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==31276== For more details, rerun with: -v ==31276== ==31276== Thread #1 is the program's root thread ==31276== ==31276== Thread #1: lock order 0x58F499C before 0x58F494C violated ==31276==at 0x4025D47: pthread_mutex_lock (hg_intercepts.c:409) ==31276==by 0x4030D86: OpenThreads::Mutex::lock() (PThreadMutex.c++:122) ==31276==by 0x45C4D4C: OpenThreads::ReadWriteMutex::readUnlock() (ScopedLock:31) ==31276==by 0x45C2BBE: osgParticle::ParticleSystem::drawImplementation(osg::RenderInfo) const (ReadWriteMutex:90) ==31276==by 0x43E48C3: osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) (Drawable:898) ==31276==by 0x43DF2DD: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:419) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:384) ==31276==by 0x43DF36E: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:469) ==31276==by 0x43E6FF3: osgUtil::RenderStage::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderStage.cpp:1251) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:384) ==31276==by 0x43E811D: osgUtil::RenderStage::drawInner(osg::RenderInfo, osgUtil::RenderLeaf*, bool) (RenderStage.cpp:845) ==31276==by 0x43EB505: osgUtil::RenderStage::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderStage.cpp:1108) ==31276== Required order was established by acquisition of lock at 0x58F499C ==31276==at 0x4025D47: pthread_mutex_lock (hg_intercepts.c:409) ==31276==by 0x4030D86: OpenThreads::Mutex::lock() (PThreadMutex.c++:122) ==31276==by 0x45C4DE4: OpenThreads::ReadWriteMutex::readLock() (ScopedLock:31) ==31276==by 0x45C2AFA: osgParticle::ParticleSystem::drawImplementation(osg::RenderInfo) const (ReadWriteMutex:89) ==31276==by 0x43E48C3: osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) (Drawable:898) ==31276==by 0x43DF2DD: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:419) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:384) ==31276==by 0x43DF36E: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:469) ==31276==by 0x43E6FF3: osgUtil::RenderStage::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderStage.cpp:1251) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:384) ==31276==by 0x43E811D: osgUtil::RenderStage::drawInner(osg::RenderInfo, osgUtil::RenderLeaf*, bool) (RenderStage.cpp:845) ==31276==by 0x43EB505: osgUtil::RenderStage::draw(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderStage.cpp:1108) ==31276== followed by a later acquisition of lock at 0x58F494C ==31276==at 0x4025D47: pthread_mutex_lock (hg_intercepts.c:409) ==31276==by 0x4030D86: OpenThreads::Mutex::lock() (PThreadMutex.c++:122) ==31276==by 0x45C4DFD: OpenThreads::ReadWriteMutex::readLock() (ReadWriteMutex:37) ==31276==by 0x45C2AFA: osgParticle::ParticleSystem::drawImplementation(osg::RenderInfo) const (ReadWriteMutex:89) ==31276==by 0x43E48C3: osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) (Drawable:898) ==31276==by 0x43DF2DD: osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) (RenderBin.cpp:419) ==31276==by 0x43DEFFE: osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*)
[osg-users] segfault: particle/threads (was: Re: svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-))
* 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 in #20 and #21 are strange. Haven't seen that
before.)
m.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb678b6f0 (LWP 9931)]
osgParticle::ParticleSystemUpdater::traverse (this=0x887a668, n...@0x89fa9c0)
at /home/m/fgfs/osg/include/OpenThreads/ReadWriteMutex:103
103 ScopedWriteLock(ReadWriteMutex mutex):_mutex(mutex) {
_mutex.writeLock(); }
(gdb) bt
#0 osgParticle::ParticleSystemUpdater::traverse (this=0x887a668,
n...@0x89fa9c0) at /home/m/fgfs/osg/include/OpenThreads/ReadWriteMutex:103
#1 0xb7dc0520 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0x887a668)
at /home/m/fgfs/osg/include/osg/NodeVisitor:191
#2 0xb7f2c791 in osgParticle::ParticleSystemUpdater::accept (this=0x887a668,
n...@0x89fa9c0) at /home/m/fgfs/osg/include/osgParticle/ParticleSystemUpdater:44
#3 0xb7bb64fa in osg::Group::traverse (this=0xd491b40, n...@0x89fa9c0) at
/home/m/fgfs/osg/src/osg/Group.cpp:62
#4 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0xd491b40)
at /home/m/fgfs/osg/include/osg/NodeVisitor:191
#5 0xb7bb7f2f in osg::Group::accept (this=0xd491b40, n...@0x89fa9c0) at
/home/m/fgfs/osg/include/osg/Group:38
#6 0xb7bb64fa in osg::Group::traverse (this=0xcfc4340, n...@0x89fa9c0) at
/home/m/fgfs/osg/src/osg/Group.cpp:62
#7 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0xcfc4340)
at /home/m/fgfs/osg/include/osg/NodeVisitor:191
#8 0xb7bb7f2f in osg::Group::accept (this=0xcfc4340, n...@0x89fa9c0) at
/home/m/fgfs/osg/include/osg/Group:38
#9 0xb7bb64fa in osg::Group::traverse (this=0x105066d0, n...@0x89fa9c0) at
/home/m/fgfs/osg/src/osg/Group.cpp:62
#10 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0,
no...@0x105066d0) at /home/m/fgfs/osg/include/osg/NodeVisitor:191
#11 0xb7bb7f2f in osg::Group::accept (this=0x105066d0, n...@0x89fa9c0) at
/home/m/fgfs/osg/include/osg/Group:38
#12 0xb7bb64fa in osg::Group::traverse (this=0x10506840, n...@0x89fa9c0) at
/home/m/fgfs/osg/src/osg/Group.cpp:62
#13 0xb7db9f7b in osgUtil::CullVisitor::apply (this=0x89fa9c0,
no...@0x10506840) at /home/m/fgfs/osg/include/osg/NodeVisitor:191
#14 0xb7bdd299 in osg::LightSource::accept (this=0x10506840, n...@0x89fa9c0) at
/home/m/fgfs/osg/include/osg/LightSource:38
#15 0xb7bb64fa in osg::Group::traverse (this=0x8885558, n...@0x89fa9c0) at
/home/m/fgfs/osg/src/osg/Group.cpp:62
#16 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0x8885558)
at /home/m/fgfs/osg/include/osg/NodeVisitor:191
#17 0xb7bb7f2f in osg::Group::accept (this=0x8885558, n...@0x89fa9c0) at
/home/m/fgfs/osg/include/osg/Group:38
#18 0xb7c4804f in osg::Switch::traverse (this=0x105074d8, n...@0x89fa9c0) at
/home/m/fgfs/osg/src/osg/Switch.cpp:40
#19 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0,
no...@0x105074d8) at /home/m/fgfs/osg/include/osg/NodeVisitor:191
#20 0xb7db87aa in osgUtil::CullVisitor::apply (this=0x89fa9c0,
no...@0x105074d8) at /home/m/fgfs/osg/src/osgUtil/CullVisitor.cpp:1097
warning: (Internal error: pc 0xb7c495ee in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0xb7c495ed in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0xb7c495ed in read in psymtab, but not in symtab.)
#21 0xb7c495ee in osg::Switch::accept (this=warning: (Internal error: pc
0xb7c495a0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0xb7c495ed in read in psymtab, but not in symtab.)
0x105074d8, n...@0x89fa9c0) at /home/m/fgfs/osg/include/osg/Switch:40
#22 0xb7bb64fa in osg::Group::traverse (this=0x89fe348, n...@0x89fa9c0) at
/home/m/fgfs/osg/src/osg/Group.cpp:62
#23 0xb7dbf1c0 in osgUtil::CullVisitor::apply (this=0x89fa9c0, no...@0x89fe348)
at /home/m/fgfs/osg/include/osg/NodeVisitor:191
#24 0xb7bb7f2f in osg::Group::accept (this=0x89fe348, n...@0x89fa9c0) at
/home/m/fgfs/osg/include/osg/Group:38
#25 0xb7e49f65 in osgUtil::SceneView::cullStage (this=0x89f9d80,
projecti...@0x89f99a0, modelvi...@0x89f9a20, cullVisitor=0x89fa9c0,
rendergraph=0x89fa7e0, renderStage=0x89fa830, viewport=0x893ac20) at
/home/m/fgfs/osg/src/osgUtil/SceneView.cpp:962
#26 0xb7e46b19 in osgUtil::SceneView::cull (this=0x89f9d80) at
/home/m/fgfs/osg/src/osgUtil/SceneView.cpp:828
#27 0xb7fcb728 in osgViewer::Renderer::cull_draw (this=0x89f9cb8) at
/home/m/fgfs/osg/src/osgViewer/Renderer.cpp:546
#28 0xb7fc6d9b in osgViewer::Renderer::operator() (this=0x208,
context=0x8962380) at /home/m/fgfs/osg/src/osgViewer/Renderer.cpp:689
#29 0xb7baf637 in osg::GraphicsContext::runOperations (this=0x8962380) at
/home/m/fgfs/osg/src/osg/GraphicsContext.cpp:688
#30 0xb8007e62 in osgViewer::ViewerBase::renderingTraversals (this=0x893e438
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
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 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Introducing osgpdf
* 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 -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lcairo -lX11 -lXfixes -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 $ pkg-config poppler-glib --libs -L/usr/local/lib -lpoppler-glib -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 Hmm, so it should pick up gdk-x11-2.0 and gdk_pixbuf-2.0, which are supposed to define the missing symbols. Perhaps you're pkg-config isn't picking up on the correct libs. pkg-config apparently is, and looking at the strace output it looks like cmake is as well. (Unfortunately, cmake is a bit too opaque for my taste. I couldn't yet figure out how to get the full gcc command line.) m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Introducing osgpdf
[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 right order. Unfortunately, I couldn't yet find an order that works, even after stripping out all the duplicate lib entries. :-/ Turning off -Wl,--as-needed for OSG works, though. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Introducing osgpdf
* 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://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Introducing osgpdf
* 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, it wasn't for me until I moved it). Isn't built here either, probably for that reason, although poppler cairo are installed. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Introducing osgpdf
* 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 `gdk_pixbuf_get_n_channels' /usr/local/lib/libpoppler-glib.so: undefined reference to `gdk_pixbuf_get_rowstride' /usr/local/lib/libpoppler-glib.so: undefined reference to `gdk_pixbuf_get_height' /usr/local/lib/libpoppler-glib.so: undefined reference to `gdk_pixbuf_get_width' /usr/local/lib/libpoppler-glib.so: undefined reference to `gdk_pixbuf_get_pixels' Looks like the missing symbols are defined in libgdk-x11-2.0.so and libgdk_pixbuf-2.0.so. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping
* 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 itself doesn't even write it to its files! AC3D users who want the default do now have to manually(!) insert oodles of 'texrep 1 1' with an editor, only because OSG does no longer respect the documented default. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] segfault: osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply
* 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 I'm not exactly FlightGear's OSG expert. But next time I'll be a bit more aggressive hunting it down. Is it possible to alter the threading model that FlightGear uses? AFAIK no. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] segfault: osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply
* 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. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] segfault: osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply
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 libc: 2.8 (20080425) app: FlightGear (cvs/head) db: no idea; maybe some other fgfs developer could explain that :-) The crash happens every few flightgear runs, without obvious pattern. See the attached gdb log for details. More gdb or other info on request. m. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb3e24b90 (LWP 27878)] osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, stateset=0xef260a0) at /home/m/fgfs/osg/include/osgDB/DatabasePager:431 431 if ( texture-getTextureObject(*iter) == NULL ) return false; (gdb) bt #0 osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, stateset=0xef260a0) at /home/m/fgfs/osg/include/osgDB/DatabasePager:431 #1 0xb7bfaffe in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osgDB/DatabasePager.cpp:206 #2 0xb7a9c80e in osg::Geode::accept (this=0x11460358, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Geode:39 #3 0xb7ac75aa in osg::Group::traverse (this=0x114602c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #4 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/NodeVisitor:181 #5 0xb7af399e in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:86 #6 0xb7ac8efe in osg::Group::accept (this=0x114602c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Group:38 #7 0xb7ac75aa in osg::Group::traverse (this=0x118b6c90, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #8 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/NodeVisitor:181 #9 0xb7af399e in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:86 #10 0xb7af3a54 in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:121 #11 0xb7af3aa2 in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:136 #12 0xb7ae904a in osg::MatrixTransform::accept (this=0x118b6c90, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/MatrixTransform:37 #13 0xb7ac75aa in osg::Group::traverse (this=0x1134eb78, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 #14 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/NodeVisitor:181 #15 0xb7af399e in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:86 #16 0xb7ac8efe in osg::Group::accept (this=0x1134eb78, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Group:38 #17 0xb7bf26d4 in osgDB::DatabasePager::DatabaseThread::run (this=0x904c140) at /home/m/fgfs/osg/src/osgDB/DatabasePager.cpp:675 #18 0xb79a3231 in OpenThreads::ThreadPrivateActions::StartThread (data=0x904c14c) at /home/m/fgfs/osg/src/OpenThreads/pthreads/PThread.c++:170 #19 0xb798d175 in start_thread () from /lib/libpthread.so.0 #20 0xb7524dce in clone () from /lib/libc.so.6 (gdb) print texture $1 = (osg::Texture2D *) 0x114febb8 (gdb) bt full #0 osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, stateset=0xef260a0) at /home/m/fgfs/osg/include/osgDB/DatabasePager:431 texture = (osg::Texture2D *) 0x114febb8 i = 0 #1 0xb7bfaffe in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osgDB/DatabasePager.cpp:206 i = 6 #2 0xb7a9c80e in osg::Geode::accept (this=0x11460358, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Geode:39 No locals. #3 0xb7ac75aa in osg::Group::traverse (this=0x114602c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 No locals. #4 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/NodeVisitor:181 No locals. #5 0xb7af399e in osg::NodeVisitor::apply (this=0xb3e240c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/NodeVisitor.cpp:86 No locals. #6 0xb7ac8efe in osg::Group::accept (this=0x114602c8, [EMAIL PROTECTED]) at /home/m/fgfs/osg/include/osg/Group:38 No locals. #7 0xb7ac75aa in osg::Group::traverse (this=0x118b6c90, [EMAIL PROTECTED]) at /home/m/fgfs/osg/src/osg/Group.cpp:62 No locals. #8 0xb7bfae89 in osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply
Re: [osg-users] segfault: osgDB::DatabasePager::FindCompileableGLObjectsVisitor::apply
* 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 source? yes Have others in the FligthGear community seen similar problems? I don't know of any, but it looks like most people don't update that often. OSG takes a long time to compile, and it doesn't seem to profit much from ccache. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build 8458 Problem with OpenThreads\Atomic wanting to include a missing OpenThreads\Config
* 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 @@ return ptrOld == InterlockedCompareExchangePointer(_ptr, ptrNew, ptrOld); #elif defined(_OPENTHREADS_ATOMIC_USE_MUTEX) ScopedLockMutex lock(_mutex); -if (_ptr != oldPtr) +if (_ptr != ptrOld) return false; _ptr = ptrNew; return true; #else -if (_ptr != oldPtr) +if (_ptr != ptrOld) return false; _ptr = ptrNew; return true; m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build 8458 Problem with OpenThreads\Atomic wanting to include a missing OpenThreads\Config
* 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. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixes for VRML2 plugin
* 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 as a prefix to the first dir name), but apart from that the syntax is supposed to look like this: file://hostname/C:data/blah ... whereby a localhost can be left away: file:///C:data/blah... which can be shortened to: file:/C:data/blah But file://C:data/blah is most certainly wrong. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixes for VRML2 plugin
* 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 on your disc. m. PS: Sorry for replying to the wrong list. I threw both lists in one mailbox, as I hadn't intended to post, but this has now changed. I fixed my system. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPlugins/ac/ac3d.cpp: don't strip relative texture paths
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
// AC3D loader for models generated by the AC3D modeller (www.ac3d.org)
// part of this source code were supplied by the AC3D project (Andy Colebourne)
// eg the basic parsing of an AC3D file.
// Conversion from AC3D scenegraph to OSG by GW Michel.
#include vector
#include iostream
#include osg/GL
#include osg/GLU
#include osg/Math
#include osg/BlendFunc
#include osg/CullFace
#include osg/Geode
#include osg/Group
#include osg/Geometry
#include osg/Light
#include osg/LightSource
#include osg/Material
#include osg/Math
#include osg/Texture2D
#include osg/TexEnv
#include osg/StateSet
#include osg/ShadeModel
#include osg/Math
#include osg/Notify
#include osgUtil/Tessellator
#include osgDB/FileNameUtils
#include osgDB/Registry
#include osgDB/ReadFile
#include osgDB/FileUtils
#include Exception.h
#include Geode.h
namespace ac3d {
osg::Node*
readFile(std::istream stream, const osgDB::ReaderWriter::Options* options);
}
class geodeVisitor : public osg::NodeVisitor { // collects geodes from scene sub-graph attached to 'this'
public:
geodeVisitor():
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN) {}
~geodeVisitor() { _geodelist.clear();}
// one apply for each type of Node that might be a user transform
virtual void apply(osg::Geode geode) {
_geodelist.push_back(geode);
}
virtual void apply(osg::Group gp){
traverse(gp);// must continue subgraph traversal.
}
std::vectorconst osg::Geode * getGeodes() {return _geodelist;}
protected:
typedef std::vectorconst osg::Geode *Geodelist;
Geodelist _geodelist;
};
class ReaderWriterAC : public osgDB::ReaderWriter
{
public:
virtual const char* className() const { return AC3D Database Reader; }
virtual bool acceptsExtension(const std::string extension) const
{
return osgDB::equalCaseInsensitive(extension,ac);
}
virtual ReadResult readNode(const std::string file,const Options* options) const
{
std::string ext = osgDB::getFileExtension(file);
if (!acceptsExtension(ext)) return ReadResult::FILE_NOT_HANDLED;
// GWM added Dec 2003 - get full path name (change in osgDB handling of files).
std::string fileName = osgDB::findDataFile( file, options );
osg::notify(osg::INFO) osgDB ac3d reader: starting reading \ fileName \ std::endl;
// Anders Backmann - correct return if path not found
if (fileName.empty()) return ReadResult::FILE_NOT_FOUND;
// allocate per file data and start reading
std::ifstream fin;
fin.open(fileName.c_str(), std::ios::in);
if (!fin.is_open()) return ReadResult::FILE_NOT_FOUND;
// code for setting up the database path so that internally referenced file are
// searched for on relative paths.
osg::ref_ptrOptions local_opt;
if (options)
local_opt = static_castOptions*(options-clone(osg::CopyOp::DEEP_COPY_ALL));
else
local_opt = new Options;
local_opt-getDatabasePathList().push_back(osgDB::getFilePath(fileName));
ReadResult result = readNode(fin, local_opt.get());
if (result.validNode())
result.getNode()-setName(fileName);
return result;
}
virtual ReadResult readNode(std::istream fin, const Options* options) const
{
std::string header;
fin header;
if (header.substr(0, 4) != AC3D)
return osgDB::ReaderWriter::ReadResult::FILE_NOT_HANDLED;
return ac3d::readFile(fin, options);
}
virtual WriteResult writeNode(const osg::Node node,const std::string fileName, const Options* /*options*/) const
{
std::string ext = osgDB::getFileExtension(fileName);
if (!acceptsExtension(ext)) return WriteResult::FILE_NOT_HANDLED;
geodeVisitor vs; // this collects geodes.
std::vectorunsigned intiNumMaterials;
const_castosg::Node(node).accept(vs); // this parses the tree to streamd Geodes
std::vectorconst osg::Geode * glist=vs.getGeodes();
std::ofstream fout(fileName.c_str(), std::ios::out | std::ios::binary);
// Write out the file header
std::vectorconst osg::Geode *::iterator itr;
fout AC3Db std::endl;
// output the Materials
int iNumGeodesWithGeometry = 0
Re: [osg-users] X11 keyboard bug (+ fix)
* Robert Osfield -- Monday 25 February 2008: Do you have a new set of changes pending? Are the ones from 21st Feb the latest and definitive set to review? BTW, for future submissions could you send whole files rather a diff, as per the instructions on: I sent the whole files to osg-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] To: [EMAIL PROTECTED] m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer/X11: fix for stuck-keys bug
* 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: /home/robert/OpenSceneGraph/src/osgViewer/GraphicsWindowX11.cpp:1310: warning: converting to 'Time' from 'double' Err ... I told you to take the files from the followup message in that thread, not the one from the first message. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer/X11: fix for stuck-keys bug
* 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/GraphicsWindowX11.cpp ./include/osgViewer/api/X11/GraphicsWindowX11 *This* here was meant to be submitted, not the files from the parent posting. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer/X11: fix for stuck-keys bug
* 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 because adaptKey() needs it for an XLookupString(). The time isn't needed in the event structure anyway. It's only needed for the getEventQueue()-keyPress() call. I'll submit a fix for the capslock problem. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer/X11: fix for stuck-keys bug
* 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 keycode according to the translation table. All other struct members are only filled out just in case. The event is never sent, so the time doesn't matter at all. Unfortunately, there didn't seem to be another way to get the same result as XLookupString() would return, but without having to provide an event structure. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer/X11: fix for stuck-keys bug
* 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 keyboard bug (+ fix)
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 improves a comment. The patch format is a unified diff without context, because with normal settings it very hard to read and review. The solution doesn't only solve the stuck-keys problem, it also makes osgViewer aware of keys that are in pressed state when its window receives focus. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 keyboard bug (+ ugly fix)
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 explain some more when I submit it. Please test on
different Unices, especially with multiple windows/displays.
m.
Index: include/osgViewer/api/X11/GraphicsWindowX11
===
--- include/osgViewer/api/X11/GraphicsWindowX11 (revision 7855)
+++ include/osgViewer/api/X11/GraphicsWindowX11 (working copy)
@@ -44,9 +44,11 @@
_currentCursor(0),
_initialized(false),
_realized(false),
-_timeOfLastCheckEvents(-1.0)
+_timeOfLastCheckEvents(-1.0),
+_lastEventType(0)
{
_traits = traits;
+memset(_keyMap, 0, 32);
init();
@@ -159,6 +161,7 @@
void transformMouseXY(float x, float y);
void adaptKey(XKeyEvent keyevent, int keySymbol, unsigned int modifierMask);
+int getModifierMask();
bool_valid;
Display*_display;
@@ -177,7 +180,9 @@
bool_ownsWindow;
double _timeOfLastCheckEvents;
+int _lastEventType;
+char_keyMap[32];
std::mapMouseCursor,Cursor _mouseCursorMap;
};
Index: src/osgViewer/GraphicsWindowX11.cpp
===
--- src/osgViewer/GraphicsWindowX11.cpp (revision 7855)
+++ src/osgViewer/GraphicsWindowX11.cpp (working copy)
@@ -173,6 +173,23 @@
return s_x11KeyboardMap.remapKey(key);
}
+// Functions to handle key maps of type char[32] as contained in
+// a KeymapNotify event structure or returned by XQueryKeymap().
+static inline bool keyMapGetKey(char* map, unsigned int key)
+{
+return (map[(key 0xff) / 8] (1 (key 7))) != 0;
+}
+
+static inline void keyMapSetKey(char* map, unsigned int key)
+{
+map[(key 0xff) / 8] |= (1 (key 7));
+}
+
+static inline void keyMapClearKey(char* map, unsigned int key)
+{
+map[(key 0xff) / 8] = ~(1 (key 7));
+}
+
GraphicsWindowX11::~GraphicsWindowX11()
{
close(true);
@@ -693,7 +710,8 @@
XSelectInput( _eventDisplay, _window, ExposureMask | StructureNotifyMask |
KeyPressMask | KeyReleaseMask |
- PointerMotionMask | ButtonPressMask | ButtonReleaseMask);
+ PointerMotionMask | ButtonPressMask | ButtonReleaseMask |
+ KeymapStateMask | FocusChangeMask | LeaveWindowMask );
XFlush( _eventDisplay );
XSync( _eventDisplay, 0 );
@@ -917,6 +935,119 @@
osg::notify(osg::INFO)GravityNotify event recievedstd::endl;
break;
+case FocusIn :
+{
+osg::notify(osg::INFO)FocusIn event recievedstd::endl;
+// Needed to get the following KeymapNotify event.
+break;
+}
+
+case LeaveNotify :
+case FocusOut :
+{
+osg::notify(osg::INFO)FocusOut/LeaveNotify event recievedstd::endl;
+
+// Build map of all registered modifier keycodes
+XModifierKeymap *mkm = XGetModifierMapping(display);
+std::mapKeyCode,bool modifier;
+KeyCode *m = mkm-modifiermap;
+for (int i = 0; i mkm-max_keypermod * 8; i++, m++)
+{
+if (*m) modifier[*m] = true;
+}
+
+// Send fake-releases in two passes for all keys reported as pressed.
+// (pass 0: normal keys, pass 1: modifier keys)
+for (int pass = 0; pass 2; pass++)
+{
+for (unsigned int key = 8; key 256; key++)
+{
+if (!keyMapGetKey(_keyMap, key)) continue;
+bool isModifier = modifier.find(key) != modifier.end();
+if (pass == 0 !isModifier || pass == 1 isModifier)
+{
+XKeyEvent event;
+event.type = KeyRelease;
+event.serial = 0;
+event.send_event = True;
+event.display = display;
+event.window = _window;
+event.subwindow = 0;
+event.time = eventTime;
+event.x = 0;
+event.y = 0;
+event.x_root = 0;
+event.y_root = 0;
+event.state =
Re: [osg-users] X11 keyboard bug (+ fix)
* 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 release keys when the app gets focus again. We want to do that already when it loses focus. (Otherwise a stuck repeatable key might do funny things while we are away. :-) I'll try with FocusOut, LeaveNotify, KeymapNotify. Thanks for the hint! m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 keyboard bug (+ fix)
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
the pressed/released state. On UnmapNotify all pressed
keys are released. (I didn't mess with the current-event-state's
modifier mask, as this is updated with the next event, anyway.)
Patch attached. (I'll submit that if there are no serious
objections.)
m.
Index: src/osgViewer/GraphicsWindowX11.cpp
===
--- src/osgViewer/GraphicsWindowX11.cpp (revision 7855)
+++ src/osgViewer/GraphicsWindowX11.cpp (working copy)
@@ -918,8 +918,20 @@
break;
case UnmapNotify :
+{
osg::notify(osg::INFO)UnmapNotify event recievedstd::endl;
+osgGA::EventQueue *eq = getEventQueue();
+std::mapint,bool::iterator it, end = _keyStateMap.end();
+for (it = _keyStateMap.begin(); it != end; ++it)
+{
+if (it-second)
+{
+eq-keyRelease(it-first, eventTime);
+it-second = false;
+}
+}
break;
+}
case ReparentNotify:
osg::notify(osg::INFO)ReparentNotify event recievedstd::endl;
@@ -1093,6 +1105,7 @@
//getEventQueue()-getCurrentEventState()-setModKeyMask(modifierMask);
getEventQueue()-keyPress(keySymbol, eventTime);
+_keyStateMap[keySymbol] = true;
break;
}
@@ -1124,6 +1137,7 @@
//getEventQueue()-getCurrentEventState()-setModKeyMask(modifierMask);
getEventQueue()-keyRelease(keySymbol, eventTime);
+_keyStateMap[keySymbol] = false;
break;
}
Index: include/osgViewer/api/X11/GraphicsWindowX11
===
--- include/osgViewer/api/X11/GraphicsWindowX11 (revision 7855)
+++ include/osgViewer/api/X11/GraphicsWindowX11 (working copy)
@@ -179,6 +179,7 @@
double _timeOfLastCheckEvents;
std::mapMouseCursor,Cursor _mouseCursorMap;
+std::mapint,bool _keyStateMap;
};
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] X11 keyboard bug (+ ugly fix)
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 modifier keys (let's say Ctrl and Shift) and while keeping them pressed switch the desktop (e.g. on KDE) or minimize the window. Release the modifier keys. Now, when you switch back or open the minimized window, you'll see Ctrl and Shift still activated. And it's not only an visual problem. These keys are actually not released, and pressing 'a' will now really be seen as 'A'. That's very annoying in FlightGear. One has to press and release the respective modifier keys to get the missing release event. I've fixed that here with a little hack. I doubt that it's acceptable for CVS, as it sends releases for keys that were never pressed, which might confuse some applications. But maybe the patch inspires someone to write a real fix. (UnmapNotify is sent when the window gets hidden away, and MapNotify when it's brought back.) m. Index: src/osgViewer/GraphicsWindowX11.cpp === --- src/osgViewer/GraphicsWindowX11.cpp (revision 7855) +++ src/osgViewer/GraphicsWindowX11.cpp (working copy) @@ -919,6 +919,14 @@ case UnmapNotify : osg::notify(osg::INFO)UnmapNotify event recievedstd::endl; +#define RELEASE(a) getEventQueue()-keyRelease(osgGA::GUIEventAdapter::a, eventTime) +RELEASE(KEY_Shift_L), RELEASE(KEY_Shift_R); +RELEASE(KEY_Control_L), RELEASE(KEY_Control_R); +RELEASE(KEY_Meta_L),RELEASE(KEY_Meta_R); +RELEASE(KEY_Alt_L), RELEASE(KEY_Alt_R); +RELEASE(KEY_Super_L), RELEASE(KEY_Super_R); +RELEASE(KEY_Hyper_L), RELEASE(KEY_Hyper_R); +#undef RELEASE break; case ReparentNotify: ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 keyboard bug (+ ugly fix)
* 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 in FlightGear when linked with glut or sdl. (We still support all three, but will probably go for osgviewer only.) m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 keyboard bug (+ ugly fix)
* 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 platforms, and I don't know if the X11 has a counterpart. X11 does, of course, tell you which modifiers are active. But only which modifier level (shift), not which modifier key (shift_l, shift_r), so you'd still release keys that were never pressed before. (I'm not sure if that's really a problem, but it might be.) One would have to keep track of every single key to avoid it. :-/ For me *not* fixing that in OSG is not an option. But then again, it *is* fixed for me in OSG already, so ... :-) m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] restrictive OpenSceneGraph-Data license (was: Re: camera config file?)
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 own version from one of the files and distribute it with an (L)GPL project, due to the non-commericial clause. Could this, please, be reconsidered? At least reverse the license logic to make everything (L)GPL, *except* this and that. FlightGear aircraft developers extracted the fire smoke part of cessnafire.osg and modified it, but we can't distribute anything of that with FlightGear, as GPL explicitly allows commercial use. Is there another, *free* source with *.osg samples demonstrating features like particles, etc., which one can actually use? m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] restrictive OpenSceneGraph-Data license (was: Re: camera config file?)
* 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 it. So, David can't take a camera config file, adjust it to his needs and distribute it with a GPL project. This would be derived work. How I'd very much support the community rally around and creating a new data repository with everything under a much more permissive license. I'm not a modeler or content creator though. FlightGear's repository is full of free models, which you could take under the GPL. But it's no source for OSG specific stuff. And without free demos available it's unlikely that it ever becomes one. Anyway, could you at least fix the embarrassing spelling of commercial in the OpenSceneGraph-Data/README? ;-) m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
