Ok, I’ll have a look at uninit to see what’s killed and should not probably. Does scrolling work with the right speed? or is it half or double what you’d expect? On my system it’s fully OK… (have a testing app that I use on various drivers)
Scrolling is working with right speed and horizontal size is correct, only vertical size is wrong.
1 Like
ok. I tested here with BWindowScreen on generation 4. I’ll also do that test on generation 7 IvyBridge later tonight to confirm it’s OK there or not.
Maybe you could also test BWindowScreen to test if you see the same distortion…
1 Like
@X512 Just tested BWindowScreen on latest nightly (32bit) on IvyBridge: works as expected (ok).
I just had a look also at the kerneldriver and accelerant concerning clone handling: my first impression is that this works OK, but I could be missing something of course.
Anyhow, if cloning is a problem when calling that hook, then I guess app_Server does not call it with BWindowScreen either…? Since my systems stay nicely responsive after using a clone.
About vertical size: if that is halved, then probably in fact the width is twice too much: that will seemingly give this effect (since half the lines are outside of the screen then). Is the bytesPerRow registerprogramming working OK?
If you only see half the vertical size (so only upper half of the screen) then the width is half the width needed probably/possibly…
BWindowsScreen is unusable for me on Intel GPU without hacks because it only supports a fixed mode list without display native mode and all mode except native don’t work.
1 Like
I am very aware of it’s limitations. I did not ask because I wanted you to switch to that, I did ask you this in orde to rule out I am missing something here, so to minimize the number of variables left to look at so to speak. I meant to just do a test to see if it’s working OK or not within its limitations.
BTW My old simple testing app indeed tweaks a lot around that class using it intermixed with BScreen to get my testing job done.
It’s here (though for x64 it needs recompiling): Be-hold: Haiku unified nVidia TNT/GeForce graphics driver: Tools and technical information
Please note that it probably won’t work for you yet at least because setmode does not work (unless I expect if you boot into a 1024x768 desktop, as thats the mode it tests with)
@X512 can you modify ‘intel_uninit_accelerant’ to temporary -not- uninit the locks?
So these lines:
uninit_lock(&info.accelerant_lock);
uninit_lock(&info.engine_lock);
Update: And:
uninit_ring_buffer(info.primary_ring_buffer);
I think they may only be uninited by the primary accelerant…
If this fixes your problem I’ll update that in the driver.
Ah Update: indeed app_server does not uninit the accelerant (I see no log messages in syslog).
For BWindowScreen I am still interested if my testapp works OK for the other problem you are seeing.
2 Likes
Ideally it would know when it’s not available on the hardware and return B_NOT_SUPPORTED. But in the current state, the intel_driver says it can do it, but then if you call wait_for_retrace, it locks forever. This results in GLTeapot showing only a black window, for example. That’s why the timeout was added.
There are several other problems with the implementation, for example if you have multiple displays, wait_for_retrace will wait for a vertical blank on any display. So if you have two 60fps displays, you can see GLTeapot running at 120fps, twice as much as needed. Ideally, wait_for_retrace should be tied to one specific screen, but at the time I implemented it, there was too much mixups and guessing about which pipe is connected to which screen in the driver.
3 Likes
Thanks for the explanation, though indeed I gathered as much. I would probably have done the same 
For now it’s good enough I’d say. I only mentioned it in the ‘hunt’ for the trouble x512 is/was experiencing.
3 Likes
10 Likes
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