Do you run Haiku under VM?
It could be an issue with mouse position being absolute and not relative, which could lead to a guest mouse position programmatically set being erased by new, absolute, position as soon as you move the mouse on the host machine.
The main problem here is that we donāt have an OS-side way of managing the mouse in this way. It shouldnāt be up to the application to move the pointer to do this, instead the OS should report relative mouse movements in BMessages and allow the relative movement to work even when the pointer is at the edge of the screen.
Then the OS could do the right thing even on touchpads and other absolute pointing devices, and all the app would need to do is lock the focus to continue to get events.
I run it under VirtualBox, thatās correct. I tried already capturing the mouse in the VM. This way the mouse is fully handled by the VM. The result is the same. So I assume itās an actual issue of messages somehow getting messed up.
I think the main problem here is that the BView seems to manipulate the mouse position on screen depending on the received message. Somebody mentioned my set mouse pointer could be fumbled with by a queue message resetting the mouse position. This leads me to this conclusion. In this case the main problem is that the message consumer manipulates the mouse position instead of the input server and that sounds to me like a major design problem. The input server should be the authority and if it gets a set mouse point message it acts accordingly. From looking at the code I had the impression this is the intended way of things to work but somehow it doesnāt?
if an input_server device push absolute mouse position, Iām not surprise that a previous set_mouse_position() is fumbled as soon as the mouse device is moved.
If itās the case, weāve indeed a design flaw in our mouse position management.
Which deserve a bug ticket (if there isn"t already oneā¦)
Did somebody change code? The mouse pointer re-centering is now working and I had been busy at other places in the code base. Aaaaaanyways.
I tried not getting the input to work properly. Doing so I noticed a strange behaviour. Pressing and mouse button you can query the modifier keys. I found no constants for this so I good old printf and checked out what happens if I press this or that key while pressing the mouse button. Interestingly I noticed this:
Left Shift => 257
Left Control => 4100
Left Alt => 1026
Right Shift => 0
Right Control => 0
Right Alt => 0
Funnyā¦ the modifier keys on the left side of the keyboard are reported correctly but the ones on the right side are not reported correctly. I guess this means I have to track the keyboard state myself?
From InterfaceDefs.h Ā« interface Ā« os Ā« headers - haiku - Haiku's main repository
Left Shift => 257 => 0x101 => B_LEFT_SHIFT_KEY | B_SHIFT_KEY
Must be a bug somewhere that the right side doesnāt work.
How far away is hardware acceleration and support for blender3d are we talking months or years?
1 Like
Hardware 3D acceleration: years.
Blender: it is already working, but without acceleration, it is slow.
Yeah Iāve heard they got it to run on Haiku but I canāt see the point if itās running slow.
It really need that acceleration to be a viable option.
to me it is the big lack in haiku, cause i really need blender and thats is basiclly the only reason why i still using linux 
Blender is working on Haiku? Where is this?
1 Like
I have a really old BeOS port on my repo. More for inspiration than anything else. If anyone has a properly working one that they need hosting for, Iād be happy to work with them to package and host it.
https://depot.haiku-os.org/#!/pkg/blender/clasqm/2/11b/-/-/4/x86_gcc2?bcguid=bc248-FFDJ
Oh my godā¦ blast from the past! Never seen such an old version since ages 
That looks definitely better.
@Topic: Managed to get things running for the first time nowā¦ sort of.
Canāt snap or tape it yet but itās rendering something. Since Iām though on 4.3 OpenGl using the hack mentioned in this topic things render broken (obviously Mesa canāt keep up with AAA grade render techniques yet) and slow (1-2 FPS) but at last it does something. Letās see where this goes.
I had though to compile all with ā-gā. It looks like the GCC4 in Haiku has a nasty bug. The exact same code compiles fine with ā-gā but if compiled without the compiler messes up turning some memory location NULL right after assigning to it. If I put in an if(!var) check (which is never fired) the compiler manages to compile correctly but without it fails. I tried also with -O1 instead of -O2 but no dice. Something is wrong with the GCC4 in Haiku. Mind upgrading? Chances are itās an upstream bug solved in the mean time.
EDIT: This bug happens only on Haiku. Neither Linux, Windows, Android nor MacOS shows this bug in this code.
There is no gcc4 anymore in Haiku, better to say not in nightly builds.
Are you still using Alpha4?
Has the nightly GCC5 then? Whatever the caseā¦ itās the GCC in nightly build which is bugged.
Yes, we are currently using gcc5. Switch to gcc6 is work in progress and 7 will come after that.
Yeah, iām trying to get out of the habit of using the gccX language to describe builds since it leads to a lot of confusion.
At this point, since we decided x86_gcc2 is the ā32-bitā release and x86_64 is the ā64-bitā release, sticking to these names is a safe long-term bet. (Dropping x86 as a target made this all a bit clearer which is reflected on our new nightly image download page: https://download.haiku-os.org/)
1 Like
regarding right shift detection, there is a command line tool, āmodifiersā, available which will dumps active modifiers when called with -list argument
I run a quick test under my VM on a hrev51353 x86_64 and when right shift is pressed, it does detect it correctly:
~> modifiers -list shift,numlock,rshift
When both are:
~> modifiers -list shift,numlock,lshift,rshift
So I guess if it was broken, it has been fixed since.