Does it use the same techinque hence reading the “modifiers” from the BMessage extra data? Because I notice the problem there.
It calls modifiers() to retrieve the modifiers current mask. This mask is kept up-to-date by input_server as key down events are received from input device(s) and sent to focus handlers so, yes, I will say it does use same technique than any app using the “modifiers” field of a key down BMessage.
What version of Haiku are you running? x86 or x86_64 ?
What version of Haiku are you running? x86 or x86_64 ?
Also, which keymap? It would not be the first time that we find a broken keymap in Haiku. Maybe someone made a keymap where both shifts are “left”?
oh, yes, the keymap could be culprid too, indeed.
@dragon, you can check via the Keymaps app to see how your keymap or other behave regarding right shift detection.
It’s x86_64 and keymap is Swiss-German. From using the keymap preference app and pressing the two shift keys I get the impression the keymap does distinguish them. But “modifiers” fails to handle it. That’s strange.
The keymap app highlights the physical key you press, so that should always be correct (unless your keyboard has strange hardware wiring, but this is not the case here).
However, this is then mapped to “symbols” by the keymap.
However, I don’t see anything strange in the swiss-german keymap file, both shift keys are in the right place there.
This is strange. Somebody changed something affecting the nightly build? I can’t reproduce it anymore. When I tested it I had it only MouseDown messages showing the problem. Now it doesn’t show up anymore (granted, I didn’t update the nightly since a couple of days). Better like this I guess but it’s still strange.
Side Question: Any plans on upgrading Mesa in the future? Using the version hack does allow things to run but graphics fail since most probably the current Mesa can’t handle something properly.
You mean the MESA_GL_VERSION_OVERRIDE trick ?
While we could enforce it in our port, I guess the version promotion is officially in the hand of Mesa guys. I ignore why they stay with 3.0 compatibility version currently, but I guess they have a good reason for that.
Yep, this one. I guess I need to fiddle with the options a bit to see what feature breaks on Haiku MESA. My guess would be transform feedback. If a driver messes this one up result can be ugly and broken.
A little screenshot might be okay. Still various problems existing (as well as MESA being horribly slow) but it’s a start:
4 Likes
Tried getting a grasp on this packaging system of yours. I want to integrate it straight into the build process as I did with everything else so far. Seems to work so far.
But I did not fully get where files go. These package things seem to be read-only directories which is in some cases a problem. Perhaps somebody can help me out where files should go to properly work.
-
/boot/system/bin : On Linux I put stuff in /usr/bin. Here I seem to have /boot/system/bin and /boot/system/apps. What’s the difference? I’ve got terminal and gui binaries. Are they split into these directories? Or do things go completely elsewhere?
-
/boot/system/lib : Looks like this is /usr/lib as I use under Linux. Some libraries are versioned, many not. Which one is the idea here? Also there is /boot/system/develop/lib which seems to be full of .so files too. What’s the difference?
-
/boot/system/share : Under Linux I put things under /usr/share. Is this the same thing?
( lib/share : I allow updating modules and shared files inside installed directories, for example updating modules or shared files. As I see it those are read-only. Is it thus not possible to do “auto-updating” only using system wide updating?
-
/boot/system/develop/include : Seems to me to be /usr/include. Anything wrong here?
-
/boot/system/config ? : That one I don’t get. Under Linux I used /etc . I put there global read-only configuration. Is such a place existing on haiku too?
-
/boot/home/config ? : Seems to be /home/USER/.config under Linux. For per-user writeable cofniguration.
-
/boot/home/cache ? : Under Linux I use /home/USER/.cache for cache files. Is there an explicit place for this under Haiku or can I “make this up”?
-
/boo/system/documentation ? : Is this comparable to /usr/share/doc under Linux? It seems quite empty here except man and info pages. What kind of documentation does Haiku require actually?
Thanks for help in advance.
You may find some answers there:
https://dev.haiku-os.org/wiki/PackageManagement
In particular give a look at :
- https://dev.haiku-os.org/wiki/PackageManagement/DirectoryStructure
- https://dev.haiku-os.org/wiki/PackageManagement/PackagingPolicy
/boot/system/bin are for non-gui binaries and scripts, non-system daemon included. The one from packages
/boot/system/apps | demos are for gui applications. You can add yours under a subfolder.
/boot/system/preferences are for gui Haiku’s system-wide preflets.
/boot/system/servers are for Haiku’s daemons.
/boot/system/lib are for shared libs indeed, they better be versionned, but it’s not mandatory and not all are.
/boot/system/develop/lib are where linkers should search libraries to link with at build time. It’s full of symbolic link to actual shared libs under /boot/system/lib, but it also contains some non-shared or only revelant to development process stuff, like static variant of librairies, gcc’s C runtime objects file and also PkgConfig info are located there, under a pkginfo subfolder.
For your own lib(s), you should place it under /boot/system/lib and a symlink to it under /boot/system/develo/lib, for instance, don’t duplicate them.
/boot/system/share is deprecated, it’s now /boot/system/data//… and it’s where your /usr/share//* stuffs should be located now, yes.
/boot/system/develop/headers is where should be put all your devel libs API headers files. Nothing wrong there, our gcc and cmake and so on build systems know where to search headers. Haiku is not an Unix, therefore it has its own directory layout. For portability sakeness, portable software build system should not assume everything is like some Unix or Linux…
/boot/system/settings will host system-wide configuration files indeed. By default packages entries there are readonly IIRC, but you can explicitly allow files to be writable too.
/boot/home/config/settings are for per-user’s config files. Put your under a subfolder named after your package name.
/boot/home/config/cache are for per-user cached data. Again, put yours, if any, under a subfolder named after your package name.
/boot/system/documentation is doc root. For packages’s documentation there is a packages subfolder. Put yours under packages/ sbfolder.
All these are far easier to handle with an HaikuPorts recipe. Which you’ill need to do if you want your package to be automatically rebuild when one of its dependencies is updated, Haiku included.
I would recommend to use a Haikuporter recipe (even for non Haikuports stuff).
You can then use variables to place artefacts where they should be.
for instance: $includeDir for headers, $libDir fir libs.
1 Like
This explains some parts but still some questions remain:
- /boot/system/{bin,apps} : What’s the difference? should I put in bin or apps?
- /boot/system/{var,cache} : They are marked both writeable. Do they work the same as Linux? (hence cache not guaranteed to remain across reboots, var guaranteed to remain over reboot)
@korli “package” works fine. Everything else is not an option (crossplatform build system).
This is strange. I updated haiku again and rebuild from scratch to test the new directory structure and now runtime fails with a strange error not existing earlier:
resolve symbol “_ZTI11BGLRenderer” returned -2147478780
Is this linked with this ABI breaking stuff? I’m not using BGLRenderer only BGLView.
BGLRenderer is a part of the backend to BGLView and allows different renderers for BGLView to be easily added. As for the missing symbol…I’m not sure why it’s complaining about that…
The funny part is that the graphic module (which is linked against be, game and GL) loads correctly (so the linker does not see anything wrong) but while creating the BWindow containing the BGLView this message is printed to the console and then things crash. Something wrong with dynamic loading the module inside BGLRenderer? I did not change anything on the setup since I last rebuild all a couple of days ago. Only thing that changed is having updated haiku (I did not update since the breakage warning posted here, now I did to see if things still work).
on x86_64 (and on buildbots repositories), mesa provides now a versioned libGL.so.1 (instead of libGL.so). Earlier for instance for GLTeapot the SONAME was weirdly the path to the library on the buildbot server.
I think you need to rebuild your binaries.
I’ve done a full rebuild on them already. This is how I noticed the breakage. Maybe something else in the haiku image has not been properly rebuild? I checked with printf’s and the BDirectWindow+BGLView is properly constructed at runtime spouting out this message (plus “renderer not found” which it did not before the latest haiku update) and causing strange bugs later on.