Hi @rudolfc I am getting a black screen, this time on hrev55482.
As I did a recent upgrade skipping several hrevs, I am not sure which one caused the regression.
I have created ticket 17307 with attached syslog.
2 Likes
Hi rudolph I get black screen with 55489 same or similar card then Yan64…
Syslog I added to Yan’s ticket #17307
Hi Bruno, yes, saw it. In the meantime I reponded as well. All in all your card is generation 9, which is not really supported yet in the driver.
Personally I don’t have newer cards here yet so it’s hard to solve issues there atm for me. It would require a lot of comms between us to pinpoint exactly where it ‘went wrong’, though the result might be that all in all it’s quite OK and you are just starting to see first hardware interaction working: Unfortunately destroying your output for now…
Thinking about this there’s one commit that comes to mind that could be of influence, though it is not faulty:
https://git.haiku-os.org/haiku/tag/?h=hrev55436
Hrev 55483 was just fine. If itvwas not the driver causing the problem how to proceed? There must be a change between this two hrevs…
55487
Try to pinpoint via nightlies where exactly it stopped working I’d say…
In the syslog isnt there the output of 55483 and 55487?
It is this Laptop:
Hmm, I looked at the syslog, but it’s incomplete and I therefore don’t trust it very much. Is it possible for you to create seperate and complete (booting wise) syslogs from the revs?
1 Like
Ah ok Rudolph.
I will add the syslogs one by one with hrev number to the ticket #17307!?
Ia this ok?
1 Like
Think one of the first revs destroyed my screen on IvyBridge. But will get back after pinpoint the rev.
Edit:
Sorry it was IronLake that was working before. Will do a ticket…
Intel HD Graphics (IronLake, Gen5) - now works OK on hrev55482.
2 Likes
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.
1 Like
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.
3 Likes
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;
}
};
7 Likes
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!
6 Likes
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
4 Likes
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.
4 Likes