Testing Rudolf's Intel driver on Thinkpad X220

[pulkomandy]

Hi,

So, finally I had some time to test this new driver everyone is talking about!

A description of my setup

I use a Thinkpad X220 which is a SandyBridge machine. I use the internal LVDS display which is working fine with the current driver. I have a docking station with VGA and DVI output (and DisplayPort but I don't have cables for that). I have a Dell P2311H display (1080p) that I'd like to use with this laptop, but is currently not working.

Tested scenarios

First of all, I booted with just the LVDS internal display of the laptop, and nothing else. I got to a desktop in the correct resolution (that's a good start). From there, changing the refresh rate results in a black screen. Changing the resolution results in distorted display for "close" resolutions (for example 1360x768 or 1280x800) and I can press escape and get back to the working native resolution. Changing to lower resolutions (1024x768 for example) results in a black screen with a few flashing pixels on the left side and a flashing bar at the top.

This is a regression from the currently in-trunk driver, which supports switching resolutions with panel fitting.

Changing colordepth and display brightness is working ok.

Then I connected external displays. In each case, I tested first with booting with the laptop display active, and then switching to the external display from the BIOS (using keyboard shortcuts) and then booting Haiku with the external display enabled.

For DVI:

Booting with the laptop display on results in working display on the laptop. Nothing on DVI side.

Booting with the DVI display on results in black screen on both displays.

For VGA:

Booting with the laptop display on results in a broken display on the laptop, and nothing on VGA. Note that with the current driver, this configuration results in visible display on the laptop at 1024x768, a resolution that now doesn't work, with the same "broken display" symptoms.

When booting with the VGA display on, both displays end up being black.

I will attach syslogs from these various tests. Let me know if I need to try something else.

[pulkomandy]

Booting with DVI screen connected, BIOS set to display on laptop

[pulkomandy]

Boot with DVI screen attached, and enabled in BIOS

[pulkomandy]

Boot with laptop display only, try a few mode switches

[pulkomandy]

Boot with laptop display only, change color depts

[pulkomandy]

Boot with VGA connected but disabled in BIOS

[pulkomandy]

Boot with VGA connected and enabled in BIOS

[rudolfc]

Hi and thanks! So if I understand you correctly on your system current git behaves 'better'than the v4 testdriver. Correct? Anyhow, I'll commit the panelfitter stuff coming monday, where per pipe just one fitter will be programmed instead of all at the same time. Once that's there, maybe, if you have the time, you could see what needs to be -not- executed for a laptop panel to be 'at its best'. For instance setting refreshrates on laptop panels generally speaking is not such a good idea in my experience, so I can image that needs to be blocked in the code (or fixed mode-wise) when it's determined it's programming an internal panel. Or maybe it's something else (fitter, M/N programming) that requires special attention in such a case. Unfortunately I cannot test for this myself (yet) since I have no laptop available for these kind of tests. The goal for now would be that the focus is on the internal panel, not the external connections.

That being said, the items are correctly working and need to be configured per connected screen when 'dualhead clone'mode is to be attempted. An interesting subject I'd say ;-) Along (of course, wishfull thinking wise) with in the end or somewhat sooner app_server support for real seperated dualhead modes :-)

[rudolfc]

I'll walk through your syslogs asap, but I have a weekend 'off'currently so I cannot program atm..

[pulkomandy]

Yes, the short version is that in the current git driver I can use different resolutions on the internal panel, but after your changes it is not working.

And yes, if I remember correctly, the idea for laptop panels is that I never touched the panel registers, only the CPU/northbridge side things and the panel fitter, letting the panel itself always run in its native mode. On my machine this gave the better results.

It is also why I have allowed downscaling using the panel fitter (going against Intel recommendations, I think): it would allow clone mode with the external display at 1080p, and the internal one scaled from that to its lower native resolution. But this does not work reliably on all hardware and on all resolutions.

This complicates my testing a bit: when connecting an external display, its EDID info is used, and it's not possible to use the laptop panel native mode which isn't in the list then.

All these little things would be more easily solved with true dual head mode than clone mode...

[rudolfc]

Hi, Could you please test hrev55159 to see if your internal panel (still) works OK? I relocated the link and fitter programming to -after- the hardware mode thing, using the hardware mode instead of the normal target mode. If you see a problem here, please disable this piece of code for LVDS for now (#if0) I'd say, or better yet, see if you can update/improve this! :-)

If it -does- work correctly, I can imagine that also generations newer than 6 (line 511 after commit) would behave likewise as generation 6. (?).

For dualhead tests (extra screen): I have seen that for some reason both pipes are actually pipeA, so something in the assign stuff (init common or so?) is not entirely right. The BIOS programs pipeA -and- pipeB if two screens are connected on Ivy and Sandy desktop systems at least, where the driver simply overwrites pipeA with the pipeB stuff currently.

Thanks!

In the meantime I'll have a look at the displayport stuff this week.

[rudolfc]

Hi, since hrev55168 the monitor detection i.e. has been updated, so I expect behaviour changes (in the right direction).. Now next up I'll dive again into the dualhead thing: if the internal problem with always working via linkA is solved most users will have dualhead clone mode running I expect. At least I see it here on all connection types intermixed already.

The driver hits the TODO message now also for the displayport setmode routine, so that is next after that..

[pulkomandy]

Hi,

I updated my Haiku install today. The base setup (with no extrernal displays) is still working.

Then I connected a VGA display (as secondary display). I got an app_server crash. But this time the internal LVDS panel was working.

I have DisplayPort ports but I do not use them, so I think it is safe to ignore them.

I will attach the syslogs and the debug report

[pulkomandy]

hrev55169, vga connected

[pulkomandy]

hrev55169, vga connected

[pulkomandy]

hrev55169, vga connected

[rudolfc]

Thank you. Did you connect your analog display before boot or after? I don't see any recognition of that display in both logs..

Anyhow, seems fPipe == NULL at the crashing moment in Port::Power. I'll add a zero pointer check there. :-)

If you connected your analog screen while Haiku was already running, can you retry connecting it, but before boot and upload a syslog from that along with a description of what you see happening?

[pulkomandy]

It is connected before boot, and it was detected. I know this because the internal display switched to 1024x768, which it does when there is another display.

This also means some progress here: the 1024x768 mode is working again :)

I guess I did not get the correct syslog, then.

[rudolfc]

OK, thanks. Can you try hrev55174? Added a NULL pointer check to prevent the crash. Please upload a syslog again from the test with the analog screen connected :-)

[pulkomandy]

Crash is gone and analog screen is showing something now. Progress!

The display on the laptop is ok (both at 1024x768 and 1920x1080).

The display on the VGA output is shifted to the bottom and right, and is "wavy" (lines are slightly shifted to the left and right alternatively).

[pulkomandy]

Hopefully correct syslog this time

[rudolfc]

Hi, thanks. Please test hrev55176 and upload a new syslog. The analog screen should now get a pipe assigned (and will probably shut-off ;-)

[waddlesplash]

Hi rudolf: it seems whatever email you are using to make these commits is not subscribed to the haiku-commits@ mailing list, so the commit notification emails are getting bounced. Could you please rectify that? :)

[rudolfc]

Ah, OK, so -that's- the problem. I was wondering why I still did not see messages coming in. This means that something must have been changed over the years there since I never unsubscribed this adress from that list.

Strange..

The first commits a year or two ago (when my commit access was restored) I did using another account. The account I am using now -should- have been known there.

[rudolfc]

Update: Indeed, I -am- subscribed. Please rectify the problem -for- me then.. ;-)

(I am rejected because already subscribed)

[pulkomandy]

syslog after hrev55176

[pulkomandy]

Replying to rudolfc:

Hi, thanks. Please test hrev55176 and upload a new syslog. The analog screen should now get a pipe assigned (and will probably shut-off ;-)

New syslog attached, I confirm the external display is now off. It is however the one listed as active in Screen preferences, and I can only pick video modes from its EDID data for use on the internal panel.

[waddlesplash]

rudolf: Are you subscribed from the right address(es)? Your Gmail one appears to be the one you are committing from. Also, check if you have multiple email addresses in Gerrit; make sure you have the right "primary" one set.

[rudolfc]

waddlesplash: Ok, checked that in gerrit just now. I have two gmail adresses there, and one of them I am using for commits. That's the same one that has subscriptions to a bundle of these message lists (very big number of messages coming in so I am not always able to keep up with that).

This adress was not set as 'preferred' adress, which I have now changed. I am hoping this will fix the issue then?

Thanks!

[pulkomandy]

Why is the mailing list even caring about this? I think it should just get all commits delivered, no matter what the author is. Maybe we should not put the original author in the "from" field of the commit messages and use some generic address there (and have the committer as reply-to or whatever).

[rudolfc]

Pulkomandy, thank you.

Some observations and a question here and there..

• am I correct in believing that the driver looks at the found bios preset link setup and just uses that? (I think I saw that at least). Anyhow (with only panel, or with the latest git version at least), FDI link A is used, with 4 lanes active for your LVDS panel.
• the analog port gets assigned FDI link B which is up I hope (do you see a icons screen on the analog screen during boot?). Apparantly the bootscreen on it is max 1024x768 as only a single lane is setup for that screen.
• this means currently it is not possible to use anything over 1024x768 with that analog connected screen, although if you can set 1280x960 @55Hz (or even lower) it might 'just' still fit in a single lane. (Seen that here).
• if you can specify a 1280x1024 or higher bootscreen on the analog screen though, higher res modes should work I think.
• if the B link is up, looks like it is using 'programmed' filtering (missing a fixed filter specify, although I am looking at Ivy docs atm).
• Are you able to get a working VGA screen if you select 640, 800 or 1024 mode?
• BTW I did not look at which EDID should be preferred to report from the driver, personally I would use the lowest common denominator list. I think at this moment it's not very interesting yet, would be much nicer if app_server could really handle the two screens seperately ;-)

As a last remark at this moment: I am still working on the FDI link select stuff to get dualhead working (for most users) and I think that will happen this week: by using the trick you also used for your panel (preferred link). After a day's work today I have found it's impossible to switch over to the other link correctly/reliably currently and I am assuming this is because we cannot yet successfully do the link train setup ('full modeswitch'). So I plan to work on modesetting for displayport, and I'll do a try at getting EDID over the aux port channel (might be though that our 'common' code really does not support that yet, I have to checkout that code still though).

After these items I consider my work done more or less on this, and I can do one more try on the link setup using your gerrit patch in this as well. Then, it would be nice if someone else took over again on this driver. :)

Thanks for your support!

[pulkomandy]

There is no boot screen on the external display, it stays off all the time.

I can control which screen is on using a keyboard shortcut (before booting Haiku). I could try with the external one enabled if you want. The driver behaves differently in that case.

[rudolfc]

Ah ok. Then I might 'force' a fixed filter on it, I'll think a bit about that. Extra nice in this case that you got some picture before on the analog screen then (I mean without BIOS presetup apparantly).

If you want to do that 'analog booting' test, please do: every syslog gives more info into the behaviour of the BIOSes (and their common behaviour is very interesting to find out since we can rely on that for now).

Thanks!

[rudolfc]

Hello, Could you please test hrev55189 or later for me? I'd like to get a general status update from you so to speak :-)

Also check with external monitor connected again I'd say.

Thank you!

BTW If in a day or two there are no problems outthere with this update I'd like you to add the fix to the beta3 as well. Would you do that for me? Thanks for looking at it in advance :-)

[rudolfc]

Oh BTW about commits and the mailing list:

• I just realized I don't see -any- commits, though I am subscribed. It's a mystery to me.. though
• Could it be timezone or so has something to do with it? I see my commit is done -1 day ago on the website, though I really did not commit it in the future ;-)

[pulkomandy]

I received the message for your latest commit (I had not received the previous ones). So at least one part of the problem is fixed now?

[rudolfc]

Ah, I doublechecked my mailbox. Indeed, I see them now :-) Including mine.

That only leaves the time/date problem I guess..

Thanks!

[pulkomandy]

Status update:

Without external monitor: internal LCD is working fine. With external VGA monitor: both internal LCD and external monitor are DPMS ON, but remain black.

Attaching syslog containing these two boots.

[pulkomandy]

Hello,

Tested again today with hrev55273.

With VGA display:

• Forced the VGA display to be on using the BIOS shortcut key before booting
• Booting using the default resolution (1024x768)
• I now get a picture on the VGA display, however it is unstable (slightly moves left and right) and not correctly aligned (a strip that should be on the right of the display, shows on the left instead)
• Trying to switch to higher resolutions does not work (I got a flashing dark blue thing on my display). Reverting back to 1024x768 works.
• Laptop panel remains black

With DVI display (which is called HDMI by the driver, and it's the same protocol):

• Same process, forced the DVI display on before booting
• I get a black screen on both the laptop panel and the DVI display (which goes to powersaving)

Attaching syslogs from these two tests

Another test I did, but did not grab a syslog:

• Boot on VGA, forcing video resolution to 1600x1200 (the max available in the boot menu)
• I got an "out of range" error from the display, I suspect timing problems. If that helps, I can try measuring the timings on the VGA output with an oscilloscope.

[rudolfc]

Hi pulkomandy,

do you have a status update on how the driver behaves these days, and maybe a syslog?

Thanks!

[pulkomandy]

Syslogs with hrev55720

[pulkomandy]

Hello, here is the current status:

With LCD only

• Boots normally in native resolution
• Changing colordepth and resolution works (both higher and lower resolutions)
• Changing refresh rate does not work (GLTeapot is always reporting 60Hz)

With DVI connected

Same as above, the DVI display is completely ignored

With DVI connected and activated using BIOS keyboard shortcuts before booting

• Bootsplash is shown on DVI
• After bootsplash, both displays are off (DVI goes to powersaving mode, LCD has backlight off)

With VGA connected

• Bootsplash is on LCD
• At app_server start, VGA turns DPMS-on, but both display only show a black screen (backlight on on LCD as well)

With VGA connected and activated by BIOS keyboard shortcut before booting

• Bootsplash is on VGA
• At app_server start, I get an "out of range" error on the VGA display. LCD remains black.

I have attached a .zip file with syslogs for all these cases.

The docking station has two DVI outputs, they behave the same.

[rudolfc]

Thank you for the extensive report. So when actively switching to VGA this screen is deteced. I am guessing it still does not work because the BIOS sends both signals via PipeA, which results currently in illegal setup by the intel_extreme driver, unless you were to set internal panel native mode maybe (now you tried 1024x768 which should be scaled up to the native internal panel mode. So you could try specifically the native mode to see if both outputs give a desktop.

If so, you could try to experiment with the driver to see if you can actively use PipeB for the analog screen for instance, though it might be that won't work at all since there's the FDI interface we cant control succesfully yet.

For the digital screen connection: even if actively switched on, it does not get detected. Would this screen by any chance be a DP capable screen? if so, probably a DP signal is routed over the HDMI/DVI connection, which could be the reason we don't see it's EDID yet (not yet supported on DP signals).

Don't know why the internal panel shuts off here. Anyhow, internal native mode will probably not switch things on here since the external screen is not detected at all, and the backlight is off as you stated.

On a sidenote: The things you witness on this system is a great example I guess of the trouble there still is in routing signals, which is also a problem if you'd want to detect the currently set mode with certainty in order to decide to not set a mode at all at accelerant startup time.

For me at least there's still some magic totally unknown to me in this regard in this hardware.

Thanks for the update!

[pulkomandy]

Thank you for the extensive report. So when actively switching to VGA this screen is deteced. I am guessing it still does not work because the BIOS sends both signals via PipeA, which results currently in illegal setup by the intel_extreme driver, unless you were to set internal panel native mode maybe (now you tried 1024x768 which should be scaled up to the native internal panel mode. So you could try specifically the native mode to see if both outputs give a desktop.

I did not do anything special this time, but I probably have workspace settings with saved videomodes for this display which explains the 1024x768. However, when the VGA is plugged, I only get EDID data from the VGA display, and so I can't even select the native 1366x768 resolution.

For the digital screen connection: even if actively switched on, it does not get detected. Would this screen by any chance be a DP capable screen? if so, probably a DP signal is routed over the HDMI/DVI connection, which could be the reason we don't see it's EDID yet (not yet supported on DP signals).

The display itself is DVI only. However, the DVI port is on the docking station, and possibly the docking station does displayport to DVI conversion. It's this one, I did not find a lot of info on it: ​https://www.thinkwiki.org/wiki/ThinkPad_Mini-Dock_Plus_Series_3

On the laptop itself I have only a VGA and a DisplayPort++ output. I don't have a DisplayPort to DVI passive cable to test with that.

For me at least there's still some magic totally unknown to me in this regard in this hardware.

Yes that's my feeling about this hardware as well, unfortunately it is the machine I spent most of my time trying to improve the Intel driver on... That explains why I didn't make a lot of progress, at least!

[rudolfc]

Interesting pieces of hardware, these docks, always a bit magical I think :-) I do have a suggestion or two:

• The VGA connection, did you try that through the dock or directly on the laptop?
• If you tested on the laptop directly, try it on the dock. What happens? Could be that the dock also contains a DP to VGA converter chip.. That should (be able to) work, it does on my mainboard for example. (Z170 VGA, I did find the spec/chip for tha, though I never needed to actually look at it: just knowing it's there is enough).

If the dock has a converter, could be that it works anyway already. If it has a converter, the VGA screens EDID will not be fetched, but it will be detected nevertheless if you activate it probably via the keyboard. If it doesn't get detected, you could try not the link detecttion, but a bit that's programmed by the BIOS to enable this port itself: that's sort of a failsafe (no direct DPMS or horplugging options then of course ;-)

• if you tried VGA on the dock, try on the laptop directly. But I guess you already did that. Still, you can do a extra test here as well: just modify the driver to return TRUE instead of EDID() on the analog ISConnected() routine. No EDID, but it's 'detected'. May well be the panel's EDID now gets returned to app_server and you should be able to select native mode..
• If this works, you could try the things I suggested in the previous post. Though, if you find you can get the other FDI channel going, personally I'd choose to switch the panel to B as that almost automatically means you are keeping the change local to just a few laptops of your generation. That has my preference since on most desktop systems I already saw two outputs working and indeed both the A and B FDI being up.
• More detail on the 'illegal setup': I think your current situation on the laptop with VGA connected is that both panel and VGA are routed through FDI A. FDI A link programming should I expect remain fixed for the panel. Since currently VGA is programmed as secondary output instead of vice versa (try for a test inverting that order), it's the last one to progamm the FDIA data/link registers. (Other test: don't program these at all for the VGA connection, though of course in the end something has to be found in the registers which we can read to determine automatically it doesn't need programming indeed for a setup).

• For the digital connection on the dock: try forcing the DVI output as 'detected' (return TRUE). you could test all outputs in seperate tests, one by one, until you hit the right one. If you hit the right one, there's a (maybe small, but can't hurt to try) chance the DVI screen will work. Make sure that the DVI screen is programmed last (FDI) or use native mode for the internal panel for a test.

So, the above story is the way I'd do my tests on your hardware to gain insight in how things work or don't work. I believe strongly in ruling out options, since in the stuff that remains the answer must lie..

I am just posting this story here for the case you'd like to dive in again to at least get your hardware up and running to the max. I can imagine that of course, since my head ticks the same way ;-)

Good hunting! If you do test, please share your findings at least :-)

[rudolfc]

Oh BTW: for trying the DVI output, forcing detection means, try all possible types as well, since it might run via DP or HDMI just the same (I find it rather confusing I must say, all these compatibility tricks in all hardware, though it's neat just the same)

Antother thing I am going to change in the driver is this:

• there'a eDP 'special' in the code thats actually a bit of nonsense.It will never find a connection since the preceding digital connection check will always prevail. (exact same port and bits to check after all).

For two laptops that have tickets I think the solution is here:

• remove eDP class (in theory, and on later chipsets even in practice: this port is also used on non-laptops, desktop systems sometimes)
• extend the normal class: -if- scanning portA -and- if laptop: if no edid found return VESA/BIOS edid info, and do the normal scaling setup you do for your LVDS panel or better yet the way I did it for the DDI laptops. I expect a fully working laptop in this case with correct up and down scaling. EDIT: maybe first limit this to generation 6 and 7. You have gen 5 IIRC which uses LVDS. But I have a strong feeling manufacturors beyond your generation switched to DP panels on eDP.

Another fix needed: first try to map rom ourselves, and only if that fails use the compatibility memory range. (a fail check could include for instance a full page check (256 bytes) on all ff's combined with a bios scan test result for signature ending at adress 0x10000: this is an indication we did not have access to the BIOS. All Bioses should have the signature -somewhere-..

Really, if you have time to spare, I don't mind if you help out for this kind of stuff ;-)

OK, I'll leave you in piece and quiet again for now, better I do some work for my boss again, the forum posts I do are sometimes in office hours I fear..

[rudolfc]

Oh, one more thing: have a look at this kind of thing (search for 'disassembly' for your dock):

​https://joes-tech-blog.blogspot.com/2017/09/whats-inside-lenovo-docking-station-for.html

So the HDMI/DVI probably uses this (DP converters indeed): ​https://www.paradetech.com/wp-content/uploads/2009/06/ps8312_product_brief_20081210.pdf

EDIT: I just sent a mail to the author of that disassembly webpage specifically about the VGA port on that board. If he responds I'll post it here!

[pulkomandy]

I am using the VGA port on the docking station for these tests. As far as I know, this is really a VGA port, when connected to the docking station, the laptop VGA port is disabled and the same signals are routed to the docking station.

I found some info about DisplayPort and how it handles DDC/EDID: ​https://www.ddcutil.com/displayport/

The documentation for the converter chip is not very detailed, but it looks like we should manually program the DisplayPort into DVI/HDMI compatible mode, so we can use the "AUX" lines as normal I2C, and then use that to communicate with the display. And set up the other parts of the port to use DVI/HDMI signalling as well, instead of the new DisplayPort protocol. The chip in the docking station is one of these so-called "passive" adapters.

More detail on the 'illegal setup': I think your current situation on the laptop with VGA connected is that both panel and VGA are routed through FDI A. FDI A link programming should I expect remain fixed for the panel. Since currently VGA is programmed as secondary output instead of vice versa (try for a test inverting that order), it's the last one to progamm the FDIA data/link registers.

Shouldn't the driver make sure to avoid this, and pick only one display in this case? Well I'll see what I can do about this.

[rudolfc]

Indeed, if all displays are run trhough the same FDI link it's best to pick just one screen to program and forget about the other: or just maybe it would work if all screens would not be touched, and all would run with scaling only: I am assuming this is more or less how the BIOS does it..

[rudolfc]

Hi again, schematics and a reply from the author of that blog. Uploading the pdf and below is his answer (you are correct about the VGA connector wiring):

---

good question. Lenovo calls the port on this one CS09 according to the ThinkWiki. But the pinout is not shared there, so I looked on and eventually found the archive that I have attached for you, containing a PDF with all schematics of the T400 notebook. It's one of the notebooks featuring a CS09 connector. Apparently it has 164 separate connections. You can find the diagram on page 64, and the takeaway is that the VGA signals are just routed through the connector (pins 149 .. 156), I assume the dock will connect them more or less directly to its VGA connector with no active circuitry in between. Unfortunately I no longer own the dock illustrated in the blog entry, but the schematics will probably better for you anyway.

With a little exercise you can track the dock pins back to their origin but this goes across a multitude of components (and pages). I think the signals are created in U47 (page 20) which is described as a digital out interface. It is not completely clear to me what chip that is. Could be the GPU but who knows...

Hope this helps!

Cheers,

Johannes Franke

[rudolfc]

Lenovo T400 mainboard schematics: probably same docking connector..

[pulkomandy]

Hello,

I have now retired this laptop and will not be using it anymore for running Haiku (I will convert it into a Linux machine to run my homeserver instead). So unless someone else is interested in Thinkpad X220 support, I think we can close this ticket.

[rudolfc]

OK, thanks for the heads-up. Closing ticket. If someone feels this should not have been done, please feel free to re-open it :-)