Hi, van you elaborate a bit on that commit? What does it change/fix precisely? I mean the mapping part?
I am finally poking around in app-server to check a few things on unpackaged 64 bit (no UEFI). Your pointer here I probably also have to checkout now.
Ah, I mean this commit:
.https://git.haiku-os.org/haiku/tag/?h=hrev55310
How did you solve non-booting problem of unpackaged Haiku?
For non UEFI it’s quite simple. Just from a running normal install create a new install with the installer.
When done do not boot it. Just copy all folders from the running install onto the new install, and remove all packages from the packages folder on the new install, except for the loader.
Done, now you can boot it.
This procedure does not work for UEFI as that per se keeps wanting at least haiku.hpkg there thus defeating my purpose.
This must be sitting somewhere in our UEFI loader and in my opinion that should be changed so we can use this trick there as well
I did not solve it myself, got help from someone with experience with this 
Looks like we have a problem on 64bit with publishing gfx kernel driver names. At the time acceleranthwinterface scans de folder, Both the Intel and Nvidia driver names are not there yet. But when boot is finished and I check, they are.
This is the reason gfx drivers sometimes don’t kick in on 64 bit…
Note: the drivers are in the non-packaged folder.
Update: indeed, the non packaged drivers need to be published sooner during boot. If I place the kernel driver in the system hierarchy it is found and used.
I am assuming on 32bit this works, but I’ll double-check this later on.
Yes, I think this might have been introduced with latest beta3 EFI changes. I think we should roll that back and apply a different solution. You can probably try an older EFI loader, maybe beta2.
I’ve run into this before myself, it is indeed pretty annoying. We should fix it so that non-packaged drivers work correctly. (Do we already have a ticket for it?)
Don’t know. However, it would be very nice if it would work correctly. My surface 3 for instance I could look at if that would be ok (UEFI only boot here though)
I tried different approaches but any deviation means failed boot there. And it has Intel video I’d like to have a go at 
When done do not boot it. Just copy all folders from the running install onto the new install, and remove all packages from the packages folder on the new install, except for the loader.
For EFI:
Delete the now empty packages folder, then reboot. You might have to hit SpaceBar and choose correct partition.
HTH
Out of curiosity, what are the advantages of unpackaged vs. packaged, or vice versa?
(I realize this is off the topic of this thread, so please feel free to split this off into another thread if you feel it necessary)
Non-packaged allows to change and replace just one file at a time. This is convenient when testing a driver for example, but there are risks of breaking your install (accidentally installing or deleting a file) and it makes system and sofware updates, installation and desinstallation a lot more difficult (which files need to be updated? removed? how to undo an install if something goes wrong?)
If the non-packaged directory worked as intended, it would be enough to put the modified files there, and they would automatically override the files in the packages. There are several places, however, where this doesn’t work properly. I hope we can fix this, and get the “best of both worlds” solution.
That does make sense for that sort of specific use case. I’m also crossing my fingers that it gets fixed for the cases in which it currently doesn’t work.
It mainly fixed 64 bit PCI BAR register handling. 2 PCI BAR registers can be used for 64 bit MMIO ranges.
Ah I see. The framebuffer mapping probably needs 64 bit on Nvidia too. The flag is set at least I saw on a G96 on which I am poking around a bit. Register access is down on this generation from the looks of it, but that doesn’t look to be a config space / mapping error.
Update: Going to add the 64bit framebuffer thing soon, as I just saw it’s flag also set on a Geforce 6600 PCIe.
In the meantime I can confirm it also doesn’t work correctly anymore on 32bit. Not so long before Beta3 it still did though, as that was the way I did most of my intel_extreme testing work…
This means I now had to create an unpackaged 32bit haiku version to test unfortunately.
So I should create a ticket mentioning this problem I think?
@rudolfc, Do you have an idea how to make B_MOVE_DISPLAY accelerant hook functional? It allows to move visible part of framebuffer. It is needed to implementing compositor with 2 buffers and swapping between them.
No. I don’t agree. Actually Haiku misuses this hook for offscreen drawing (did it myself as well sometimes for some tests). It is actually meant for a virtual desktop in the sense that the desktop is larger than the physical resolution of a screen, where the screen in fact is a small viewport onto that desktop. The position of this viewport is set by moving the mouse around to keep that mousepointer inside the viewport.
I have spent a lot of time in the past on my drivers (nivida, matrox, via, neomagic) to make this work flawlessly on the BeoS. I must say I was dissapointed to discover that Haiku in fact messes up in this respect.
Instead you/we need to create new hooks for offscreen compositing…
On a sidenote, I have on my old laptop a nvidia driver version that uses scaled_filtered_offscreen_blit instead of using overlay to accelerate video onto the desktop. This is using a non-existant hook I created to do this. Don’t know the exact status of it, apart from the fact that the function indeed worked. since no colorkeying is possible that way, we’d need to take into account context menus etc on top of video to only blit around that, which makes it very important to do the scaling subpixel precise to prevent artifacts on the ‘part’ rectangles edges.
Anyhow: The above expresses my personal opinion, in which I stronly believe considering use of B_MOVE_OVERLAY (only worked with hardcursor on BeOS since there was no means to track a softcursor there).
You can imagine I nolonger really look at that hook since Haiku does not recognize apparantly the intended use of this hook. Another sidenote: also the old style hardcursor support is broken for years already in Haiku (I guess since adding a fullcolor hardcursor support hooks).
Yes, I could probably make that hook work, but it would require Haiku to use it as intended, as I would be looking pixel precise to the hardware response to find the exact hardware imposed restrictions: which, at least is the old days, were also unknown and not handled on Linux dirvers.
So all in all I guess I would like it very much if Haiku developers would think long and hard about which hooks we will keep supporting for what purpose(s), and which hooks can disappear (all acc hooks from the looks of it), and which new hooks will be implemented. Considering the route we seem to want to take to only support acceleration via MESA/3D/Vulcan, all acc hooks can be deleted from the current accelerant I’d say (though I really miss them, at least on older systems, but also for video playback (since backend scalers went into oblivian in favor of acc via 3D engine AFAIK) I must say)
All in all a big response to your simple question, sorry about that. This has apparantly bothered me for years (misuse of the MOVE hook )
Still, it can be used for a temporary hack solution of course, but I really hope new hooks will come along at some point. BTW Thank you very much for your dedication and very hard work on Haiku on all kinds of subjects! Love following your work… 
I need B_MOVE_DISPLAY only for buffer swapping and tearing-free rendering. All compositing is planned to be done in software.
Rendering process will be:
It is already operational on ATI driver and QEMU, but no app_server integration currently.
In a long term accelerant API can be reworked or abandoned in flavor of DRM/KMS, but I want to complete VideoStreams prototype with compositing software rendering in this year.
I want at least hear an advice what MMIO registers should be used to implement B_MOVE_DISPLAY.
For testing that’s OK I think.
Anyhow, this hook is implemented, adresses the correct registers with the correct info AFAICT after looking at the source. My first thought is that it should work already, but your screenshot somewhere in the forum shows otherwise. Are you sure the driver is actually capable of switching modes on your system? What chipset do you have?
I’ll run my own old terminal virtualscreen testapp over here to see if it behaves correctly and I will report what I find.
UPDATE: Oh, tearfree means changing pointers during retrace only… Some hardware does that internally automatically, but also hardware exists that just does that mid-screen if not explicitly synced…
8086:0412, Intel HD/Iris (Haswell Desktop).
Thanks. Your card is a bit new for the driver. I asked you if you can set modes normally, you did not answer. Please do, as this might be the problem.
If you can indeed set modes, try a virtual mode nearer to your set desktop mode. Over here I see partial succes on generation 4: if I have my desktop at 1280x1024x32. When I keep virtual_height at 1024 I am able to increase virtual_width with correct results:
I have a wider desktop, though I cannot pan because no hardcursor is active if all is right, though it could have been implemented in app_server for a softcursor as well. Things seem to work correctly for all widths (pixel by pixel increasing) upto/including width = 1687. Beyond that things go wrong, I will look into that.
Questions to you:
I need this info. Thanks.