Not for me.
ok
hrev55114-x86_64
hrev55161-x86_64
hrev55176-x86_64
hrev55185-x86_64
hrev55207-x86_64
hrev55449-x86_64
not ok
hrev55464-x86_64
hrev55489-x86_64
So it’s ether of these. hrev55454 or hrev55451. They didn’t hade any Nightly for these.
Haiku 64bit R1 Beta 3 nightly:
55476 works ok UEFI boot from USB
55481 works ok UEFI boot from USB
55487 works ok UEFI boot from USB
55489 works ok UEFI boot from USB
Strange I have no problems found anymore?!
Do you need/want some syslog anyway?
Syslog 55481: http://0x0.st/-gCb.txt
Syslog 55487: http://0x0.st/-gCq.txt
Sysllog 55489: http://0x0.st/-gCc.txt
About Haiku: http://0x0.st/-gCT.png
EDIT: All Framebuffer! not VESA!
It is a Laptop no external monitor connected.
Nice 
only the most recent one with the Intel driver active will do 
Hmm update: The log only shows the nvidia card. I guess you need to switch to use the other card in the bios?
From your log:
vendor 10de: NVIDIA Corporation
KERN: PCI: device 1347: GM108M [GeForce 940M]
KERN: PCI: info: Display controller (3D controller)
The vesa driver kicks in because this card is not supported by the nvidia driver. Is your display connected to the nvidia card?
These two commits did not change anything that would cause the driver nolonger working.
I do have one note though: If on the latter version you did use the newer accelerant, but -not- the kernel driver you’d get into trouble, because the size of the shared_info memory was changed…
Of course that goes for all newer versions. Did you try a clean install of the latest nightly for instance?
It’s a nightly image using Etcher to get it on a USB stick.
The order I tested them was.
hrev55114 , ok
hrev55161, ok, then I thought, perhaps it was my installation that was broken I need to test the latest.
hrev55489, not ok
Then I tested them in order up to
hrev55464
I will add a syslog from the USB to my report at track.
I found a way to reduce code when using accelerant hooks. Based on Vulkan code.
#define ACCELERANT_ENTRYPOINTS_LIST(REQUIRED, OPTIONAL) \
REQUIRED(B_INIT_ACCELERANT, init_accelerant) \
REQUIRED(B_UNINIT_ACCELERANT, uninit_accelerant) \
REQUIRED(B_CLONE_ACCELERANT, clone_accelerant) \
OPTIONAL(B_PROPOSE_DISPLAY_MODE, propose_display_mode) \
REQUIRED(B_SET_DISPLAY_MODE, set_display_mode) \
REQUIRED(B_ACCELERANT_MODE_COUNT, accelerant_mode_count) \
REQUIRED(B_GET_MODE_LIST, get_mode_list) \
REQUIRED(B_GET_FRAME_BUFFER_CONFIG, get_frame_buffer_config) \
REQUIRED(B_MOVE_DISPLAY, move_display_area) \
OPTIONAL(B_ACCELERANT_RETRACE_SEMAPHORE, accelerant_retrace_semaphore)
struct AccelerantHooks {
GetAccelerantHook get_accelerant_hook{};
#define DISPATCH_TABLE_ENTRY(id, type) type type##_hook{};
ACCELERANT_ENTRYPOINTS_LIST(DISPATCH_TABLE_ENTRY, DISPATCH_TABLE_ENTRY)
#undef DISPATCH_TABLE_ENTRY
bool Init()
{
#define REQUIRED(id, type) type##_hook = reinterpret_cast<type>(get_accelerant_hook(id, NULL)); if (type##_hook == NULL) {fprintf(stderr, "[!] accelerant hook " #id " not found\n"); return false;}
#define OPTIONAL(id, type) type##_hook = reinterpret_cast<type>(get_accelerant_hook(id, NULL));
ACCELERANT_ENTRYPOINTS_LIST(REQUIRED, OPTIONAL);
#undef REQUIRED
#undef OPTIONAL
return true;
}
};
So you created: https://dev.haiku-os.org/ticket/17314
Thanks for that
As already stated there I need to put some work in propose_mode to fix the problem, which I’ll do soon. I’ll keep you informed of progress for this!
Hi, I have a small update in the ticket. The driver is updated in git so as soon as the nightlies are back up it can be easily tested. Just before the latest update in git the refreshrate was not programmed to something other the default modelines provided, so the driver was not listening to the screenprefs panel for this.
That’s fixed now…
For details please see:
https://dev.haiku-os.org/ticket/17314#comment:16
If we wanted to test or experience these drivers, should we do a full reinstall or just update on the nightly channel?
Update should be enough. Sometimes deleting screen settings may be needed.
Usually you never need full Haiku reinstall.
If you want you can test the driver I just added to the ticket (x64). This contains mods not yet committed even, still testing here. Will place it in git after that.
Update: all OK, tested on G45 (gen4) and IvyBridge (gen7 graphics). 
Update again: see hrev55517 in git. This is as is attached to the ticket (same version).
Turning monitor off seems broken on latest driver versions.
Correct. Known limitation. On G45 it works though. On newer cards it’s disabled on purpose for now.
Is is a reason of faster mode switching after boot splash?
No, i don’t think so but I’m not sure about that. Anyhow currently screen connected detection and dpms off are incompatible. Can be fixed by keeping some extra shared-info. I’ll have a second look at that at some point indeed.
Starting with https://git.haiku-os.org/haiku/tag/?h=hrev55608 the intel_extreme driver gained more support for later generation 7, generation 8 and generation 9 graphics cards, specifically for the DDI interface that these chipsets contain.
These ports are the only ones scanned now (plus the analog port if it exists) as they seem responsibe for all digital output kinds: Displaypanel (DP), HDMI and DVI.
On desktop systems where on generation 9 or later there are still analog VGA connectors, it’s signals are generated with the help of an on-board external active converter: DP to VGA, connected to the eDP chipset output (on laptops these are used for the internal panel, eDP = embedded DP). The connection between the two is a real DP connection, which means for now, as we don’t yet have support for DP style DDC/EDID channels, screens on the analog connection are not yet found. If it’s the only connected screen, output will probably work though.
Please note that you cannot yet set other resolutions than the boot resolution. What does work is:
Next up I’ll try to complete setting resolution on these systems, I guess after that more generation 8 and 9 ID’s can be set active in the driver. Though I guess for the CPU memory interface people will have to report the chip IDs on their systems, so they can be added to the GART Intel driver: that works together with the gfx driver for memory access.
If you are going to test the update, be sure to send some feedback…
Is 8086:22b0 supported?
Doesn’t look like it, but I can’t exactly locate all intel docs: ‘command reference registers’ should contain the registers for modesetting, but there’s no DDI to be found in this series, so it works differently here, or the docs are incomplete.
The ID is also not in the intel_extreme driver. I guess you could try adding it for a test but I don’t expect much at this point.
Update:
The genode folks recently implemented acceleration in their intel gpu driver, perhaps something useful can be gleaned from perusing their sourcecode?
I think that my device 8086:0166 is not in intel_gart.cpp, but to add it, I need to understand what the display_id in the struct is.
Intel gfx driver lists it as: IvyBridge Mobile GT2 but the line for it in intel_gart is:
{0x0154, 0x0166, INTEL_MODEL_IVBGM, “IvyBridge Mobile GT2”},
where the first value is the value that should match 0166.
So I probably need to add a similar line with a display_id (second value) or this line has wrong values as second value is 0x0166…
Any hints?