Hi,ppl!
I’m trying to play with Haiku Beta2 on Dell Latitude E6410 laptop with graphics integrated into Intel i5-520M.
Only way to reach Haiku desktop is by switching graphics into Vesa mode (during boot process or in config file).
Does any way exist to use HW accelerated Video on my HW?
Accelerated drivers are available only for selected ancient Nvidia GPUs.
We don’t know what kind of GPU your laptop have, so presumably your best bet is VESA for now.
1 Like
Well, may be I’m too optimistic about HW acceleration, but what about chipset specific diver not Vesa? It is Intel HD Graphics integrated into i5-520M CPU & it is 10 years old graphics.
If it is not picked up by intel_extreme driver, then probably your hw is not supported.
If you have native resolution, then you dont loose too much. Maybe the brightness control. But the intel driver wouldnt give you any extra performance.
2d acceleration is turned off in app_server so nvidia driver for old cards run without that.
2 Likes
Thats true too.
This seems to be the same graphic chipset or at least the same family than my i3-330M. My laptop panel (not external monitor) works with a little change. But first: this is low level stuff for clock configuration or something, so it may put the hardware out of specs and fry it. I really mean it, I got to that change “by chance” semirandomly touching all over the code after noticing that it reported my chipset as supported but I only got a blank screen, until I found something that got me to the desktop. I don’t know what CK505 is or should be, and the change basically deactivates a function that is there specifically for this chipset 
I have disabled the IBX path in refclk_activate_ilk, leaving hasCK505 = false and wantsSSC = true. Just removing all the code in the function and returning without doing anything also works for me. The end result in both cases seems to be that the clock is not changed, maybe I’m just lucky and whatever the BIOS does is enough.
Interesting! I think I’ll tweak this routine as well on my i5-HD-2500 (devid 0x0152) as this system also boots to a black screen. I’ll post the result here as well.
2 Likes
Once you get things further sorted out with the nVidia driver, it would be great if you could have a look at the Intel driver. PulkoMandy was the last one to dig into it. I have a pair of HP desktops with integrated graphics (Intel HD Graphics 2000/2500).
Nice you should mention that 
Actually I already spent a few hours just now on that driver, on I think possibly the exact same model HP as you have there. So: the tweak for the laptop did not help for me. I am now puzzling trough the setmode command to see where it fails: DVI doesn’t work but isn’t implemented I read somewhere, but just a VGA connection does not work either (black screen). DPMS is working though (backlight on panel is on after switch but not during it) and the mode is really active (though that could be the work of the setmode via VESA during/before boot.)
I’ve been looking at that black screen on various HP/Intel machines we have at work, so finally I decided indeed to try something small. Just looking at VGA ATM, that should be a small bug. DVI will be more work to setup.
That’s how driver development works anyway!
This change seems safe to me. It only means we are always using the “normal” clock instead of the CK505 one. The CK505 one appears to be there to reduce interference and probably get better picture quality, but it’s probably not required, and if it’s not working, we can just not use it.
I will try this on my machines as well and see if it helps. Can you submit a patch to Gerrit?
BTW Pulkomandy, if you can choose between a spread-spectrum clock and a normal clock, I strongly advice to always use the normal clock.
Spread spectrum has been invented for just one single purpose: beating the (i.e.) CE conformity tests. Quality wise it’s never better.
An update from here:
On Id 0x152 (HD 2500) I confirmed that I can boot to the desktop by choosing a lower resolution (native here is 1920x1080): I chose 1024x768. Selected with fail-safe video.
Reboot, and before the BIOS handover remove screen connector. Wait until booted and voila: desktop.
What’s working in the driver:
- apparantly setting the screen’s base adress
- setting the colordepths (I double checked on various ways)
- DPMS (I could doublecheck a bit more)
What does not work:
- setting refreshrate (PLL pixelclock)
- programming the CRTC (if I change resolution it does not change apart from what I see on the desktop)
I get the feeling some registers need to be unlocked extra on this chipset: searching for that would be my next bet.
I have the screen connected only via VGA for these tests.
Oh Update: when I try above tests with 1920x1080 the screen remains black and refresh drops to some 54 Hz. (when not disconnected it stays at 60).
Update 2: Hardcursor is also working.
Update3: If the screen remains black, the system remains responsive: no crashes, ever.
2 Likes
Yes, this is known. When the driver does not see a display connected to a port, it will not touch anything about this port. If you do nothing, the display will remain as it was initialized by VESA, and things will more or less work. But then you can’t change video modes. So you may as well just use the VESA driver.
If only it was this simple 
Intel has completely changed how displays are managed, and moved things between the southbridge, northbridge, and CPU accross versions.
In older devices, we just had to program the CRTC registers and we would get video out.
On modern devices, there is some kind of internal displayport-like link between the CPU and northbridge. We need to configure this link, and then we need to configure the VGA timings on the northbridge to match. The VGA side still uses something similar to the well known CRTC registers (but a bit different, because we still don’t get correct timings output there with our existing code). And we additionally need to configure the displayport-like thing.
Now, all the code to do this was added to the driver by kallisti5 (looking at how it’s done in the Linux driver). The Linux driver is very “by-the-book” and follows what is in Intel specs for the hardware. In our handling of older intel devices we had used some shortcuts to not re-do the complete modesetting sequence everytime, which 1) is faster and 2) allows us to benefit from the initialization done by the BIOS, that we don’t need to re-do. But we have to find what part of the settings need to be changed to use different video modes, and unfortunately it seems to be not only the CRTC registers.
Ah OK, clear. Going off-topic a bit to get your opinion on something 
I was browsing trough the nouveau DRM code BTW and I found that indeed also at Nvidia a lot has changed, for the better even (never thought I’d say -that-).
For instance they published a lot about the BIOS: all scripts are known to init all these links whereas I had to do it without any docs, and only my personal reverse engineering (for the first script type on analog VGA/init card)
Skipping the things the BIOS does is not the best idea in the long run, as you will want support for multiple graphics cards, and so you need to be able to do all the BIOS does. My nvidia driver does that and can be used without a pre-BIOS init on a lot of setups (not DVI/LVDS though).
Looking at nouveau I see this driver is very capable of doing all, so can be used as secondary cards perfectly (or do sleep mode/suspend-resume and such). I am glad I stopped where I did haha, doing a full blown gfx driver is really too much for a single person or a small team. using the linux drivers makes much more sense to me because of all that, and more.
Anyway, off-topic, sorry!
Are you planning to really do all the needed programming on the intel driver? I’m curious about the future way Haiku will take with this.
Would be cool if all recognized cards work on DVI/HDMI/VGA with BIOS pre-init as a nice ‘completed’ target for that driver. If time passes by however, more and more work will come (look at nvidia, really, that’s a whole big lot of stuff!)
3 Likes
I understand. I guess this is a bit of a downside of these integrated graphics. On nvidia’s dedicated cards this does not apply. Unless you have external encoders of course (TVencoder, LVDS encoder). For TVencoders I did some programming as well to keep stuff ‘in sync’. External encoders happen more often these days at nvidia as well come to think of it…
Anyway: if the code is there it would be interesting to test that ‘encoder’ programming part…
So here is my view on this.
I agree that a video driver is too much work for a single person. Fortunately, there are only 3 main video drivers in use today (Intel, AMD, NVidia) so if we can find 5 or 6 persons working on this, it would be a lot better.
Regarding the Intel driver, I have been stuck at this issue of not managing to get the VGA output on my laptop initialized properly. It is a bit frustrating. And this year, I am mostly working from home for my paid job, which results in the work laptop using some space on my desktop, and as a result it is not so convenient to work on graphics drivers (where I need the tested laptop, a VGA display for testing, plus another machine to build the driver on and lookup the pdf docs from Intel, maybe connect a logic analyzer to try to check the hsync/vsync outputs on the VGA port to make sure at least that is working, etc).
As a result I have not made a lot of progress.
Lately there have been discussions on just reusing the Linux code. Personally I am a bit annoyed that we would end up in a situation where the only available drivers are the ones written by video card manufacturers and integrated in Linux. I like the idea that we would be able to write our own drivers independently of the manufacturer and it seems a useful skill to preserve, maybe for other cases where a Linux driver is not available. However, that is only my personal opinion, and probably something the Haiku community as a whole doesn’t really worry about. And if someone manages to get the Linux drivers running under Haiku in some way, I will be happy to use that, and work on other things in Haiku instead. Which is what I already do for sound, using the OpenSound driver rather than trying to fix our own hda one; for network (using FreeBSD drivers), etc.
Thank you. Yes, I know the drill. Unfortunately I also spilled, in addition to having a -very- crowded workspace, a coke on my laptop so now I have a keyboard handycap as well…
I’ve been looking at Intel drm code at kernel.org. I take it the source for the driver on Haiku is not there, but directly from Intel? Can you point me at it? Maybe I can have a quick peek as well… I’d love to have a VGA picture as well.
If I understand it correctly, Intel themselves maintain a ‘open’ driver(?). This is not the case for Nvidia. They just finally released some more decent docs, and I read somewhere they even help a bit on the nouveau driver. I remember I was in contact with it’s main developer back in 2005/2006 as he suggested cooperation between our efforts. Unfortunately my own decision to quit later on meant that this never happened. Anyhow this driver is not developed by nvidia, but by the joint effort of a lot of linux users, a lot of reverse debugging/dumping tools, and other sources amongst which our nvidia Haiku driver
The Haiku driver was also ported around 2005/2006 to a German university for their own operating system I remember btw. Love that
Oops, sorry, offtopic again I think…
So would you be willing to point me at the intel driver source for linux DRM?
1 Like
Would you elaborate on this? I somehow missed this info.
1 Like
The Intel driver is maintained inside Linux at kernel.org, but there are components in other places as well (Mesa, …). A short overview is given here: https://01.org/linuxgraphics/downloads/community-source-code-repos
The Haiku driver was built from Intel documentation (not sourcecode), which can be found here: https://01.org/linuxgraphics/documentation
The documentation for the first generations of cards was quite well made. For more modern cards a lot of the documentation is “here is a list of the registers, most of them with the address where they are mapped” and there is not a lot more detail. So we have to read the Linux modesetting code and try to do things in the same way as them
I never ‘told’ this before. Nor do I remember who exactly asked my permission for this port. But since it’s MIT, and it’s kind of neat, I (of course) said: yes, of course you can do it
So you did not really miss it…
1 Like