Last comments

In response to: Debugging display problems

lorna [Visitor]
Hi,

this was useful, thanks.

"I’ll try to follow this up next week with some information on the details of current Intel display controllers "

I guess that didn't happen?
PermalinkPermalink 07/21/13 @ 03:48

In response to: Debugging display problems

phil [Visitor]
You explained this verywell. Do you have any resources how a graphics driver handles all these componets? In other words when do we make a distinction that it is a driver issue not a hardware issue
PermalinkPermalink 10/02/12 @ 14:45

In response to: Intel display controllers

jbarnes [Member]
You're in for a fun ride... doing what you want involves lots of steps (see the documentation at intellinuxgraphics.org), and rudimentary memory management at least. If you don't care about resetting modes or any dynamic configuration, you can use the "stolen" memory area the BIOS reserves for the gfx device to do your initial mode set and drawing. But for anything else, you'll need to create your own interfaces for managing memory (GTT mapping, faulting, etc), command execution, and display management.
PermalinkPermalink 02/23/12 @ 09:54

In response to: Intel display controllers

Alex [Visitor]
First of all I want to say thanks to you for your great posts about high level design of display drivers!
Currentry I am working with original OS that is microkernel and I am now trying to create a simple graphics driver for this OS. I plan to start from doing this driver for intel HD chips (I have gen5/6 video card in i3/i5 cpus). Looking at intel documentation and linux driver for these chips I get into some troubles in porting. Basically the OS that I am working with has no KMS or DRM stuff, so I need to make a driver almost from scratch. But my primary goal seems to me simple: I need to be able to setup a video card and I need to be able to switch a display modes on it. No 3D or video acceleration.
I have several years experience in driver programming (NIC, HDD, Floppy) but no experience in Display drivers.
So I need now to understand looking at linux display driver for intel HD card what stuff I need to do, what not.
I am searching now for some kind of gide about minimum setup sequence for display mode setting. Like: read pci configuration, map pci resources, parse intel HD card bios, calculate crtc regs, set crtc regs, write to video memory and get a picture on the display. As far as I understand from your blog I also need to deal with GTT (some kind of page tables from the gpu side?), encoders, pipes, ...
Please, can you explain what is the minimum setup action sequence in driver for intel HD graphics card to be able to draw a pixel on the screen?
PermalinkPermalink 02/15/12 @ 12:05

In response to: Writing standalone programs with EGL and KMS (updated)

jbarnes [Member]
My first guess would be that the mode struct you're using isn't the one for the native mode of your panel. There's more sophisticated mode picking code in the various DDX drivers, or you can just walk the lists yourself looking for the preferred mode if your connector. But it could also be a pixel vs bpp confusion; 1/4 of the width of the display in bytes is pixels, if you're running at 24 bit depth with 32 bit pixels...
PermalinkPermalink 11/14/11 @ 08:38

In response to: Writing standalone programs with EGL and KMS (updated)

David Herrmann [Visitor]
I put your code together with a simple glClear() glFinish() before the setFB() followed by a sleep(5). I get the cleared white framebuffer on the screen, however, its only a quarter of the screen. Only the left side of my screen is white, the rest stays black. However, if I draw a triangle from 1/1 1/0 0/0 it fits perfectly into the white area. That is, the whole framebuffer that I can draw into is shown on the screen but squeezed to the left side.

If I use twice the horizontal size in the gbm_bo object, then the framebuffer is shown on half the screen. However, I haven't succeeded in displaying it on the whole screen. The vertical size is always perfect, though.

Do you have an idea what could have gone wrong here? I also tried changing the pitch, but that didn't help either.
PermalinkPermalink 11/13/11 @ 07:32

In response to: Writing standalone programs with EGL and KMS (updated)

jbarnes [Member]
The screen surface extension doesn't get much attention these days, I'm not sure if it still works. IIRC it has some limitations about handling multiple outputs, so won't be suitable for a full fledged standalone console program.
PermalinkPermalink 11/09/11 @ 09:26

In response to: Writing standalone programs with EGL and KMS (updated)

gogoliu [Visitor]
why not use MESA Screen Surface extension?
PermalinkPermalink 11/09/11 @ 04:45

In response to: Writing standalone programs with EGL and KMS (updated)

jbarnes [Member]
I think there will have to be a fallback, yes. But that's up to distros. It may be that they just won't support unsupported hardware. :) It depends on the type of product they're trying to produce and whether they certify specific platforms etc. Fortunately, drivers like vesafb and friends do exist, so it's even possible to build a user level console system on hardware w/o native drivers, even if the functionality is impaired (as it would be for any device w/o native drivers).
PermalinkPermalink 11/01/11 @ 11:38

In response to: Writing standalone programs with EGL and KMS (updated)

Alexander E. Patrakov [Visitor]
OK, Intel was a bad example. Let's say "some other vendor" instead, or "qemu virtual graphics card", or just consider the case of someone in year 2015 installing a 2012's year distro on the 2015's hardware due to some stupid corporate policy. Is there any plan to handle such unsupported-beyond-vesa chipsets (other than to say "no") to users of distros with CONFIG_VT=n?
PermalinkPermalink 11/01/11 @ 11:26

In response to: Writing standalone programs with EGL and KMS (updated)

jbarnes [Member]
If a platform doesn't have any DRM drivers at all, then it would probably need to stick with the fb layer for console services and leave CONFIG_VT compiled in. But on platforms with DRM drivers, a DRM/KMS based console service in userspace could allow distros to turn off CONFIG_VT and most of the fb layer (with some refactoring) and allow for internationalized console support (both input and output). That's the main advantage.

And our current in-kernel driver supports hardware that isn't even out yet; I don't think we've been behind hardware release for at least basic mode setting support for over 5 years now...
PermalinkPermalink 11/01/11 @ 09:59

In response to: Writing standalone programs with EGL and KMS (updated)

Alexander E. Patrakov [Visitor]
You told that the existence of a userspace KMS-based console program would help cleaning up the fbcon layer. However, I don't quite unserstand why. Indeed, there are some non-x86 targets (e.g. arm) that currently rely on the framebuffer console to display any console at all. What are you proposing to do with them? What will be done with too-new Intel display hardware that is not supported by the current in-kernel driver (except via text mode or {u,}vesafb)?
PermalinkPermalink 11/01/11 @ 03:06

In response to: Intel display controllers

Ken H [Visitor]
I actually meant Arrandale for the i5 480M. If you post my previous comment feel free to make the correction. Thanks.
PermalinkPermalink 02/19/11 @ 13:19

In response to: Intel display controllers

Ken H [Visitor]
I came across your blog while searching for info re: the relative performance of the Nehalem architecture vs Sandy Bridge. Specifically with respect to mobile processors (let's say the i5 480M vs i5 2520M) is there going to be a significant difference in performance for mainstream applications? Or is the integration of the graphics engine onto the processor die mainly going to affect gaming and graphics intensive applications? I know this is probably off topic but I'm hoping you can shed some light on the practical implications rather than just saying the new architecture is faster than the old. Thanks in advance for any insight you can provide.
PermalinkPermalink 02/19/11 @ 13:11

In response to: Debugging display problems

jbarnes [Member]
No, that was intentional. I just clamped the image sizes on the post otherwise they'd be huge. You can use 'view image' to see the original size.
PermalinkPermalink 02/03/11 @ 10:03

In response to: Debugging display problems

me [Visitor]
Your blog software appears to have formatted the pictures so they became thumbnails.
PermalinkPermalink 02/03/11 @ 03:36

In response to: Intel display controllers

jbarnes [Member]
Indan, yeah that would be a good idea, keep an eye out for future chips! :) But yes, a PCH is required in most configs to provide I/O services. You just don't always have to use the display part of it.

Paul, thanks. We definitely haven't gone away, everything is still supported. I've just been slacking on blogging about it. :) In fact, there's a lot of fun stuff going on: new GLSL compiler for Mesa, lots of work around Wayland (Qt and GTK+ porting, device & driver interoperability, new display work, etc.).
PermalinkPermalink 01/27/11 @ 09:07

In response to: Intel display controllers

Paul McGarry [Visitor]
Good to see public posting on Intel graphics again. Back when I bought my last CPU/motherboard (an E6820, so some time ago) I went for Intel largely because the public posts about Intel graphics development made me confident it was well supported. Such posts seem to have dried up since then, it would be good to see more posts about the current state of Intel graphics. (It's time for me to upgrade!)
PermalinkPermalink 01/27/11 @ 03:28

In response to: Intel display controllers

Indan [Visitor]
Is the PCH mandatory or can you configure a system without it?

To me it seems it would have made much more sense to usually have no PCH at all and have two eDP ports on the CPU.

Then for the systems that want it have a PCH thing that can convert DP to VGA/HDMI/LVDS/etc. That new PCH could be used for other things than just Intel CPUs too, and systems that don't need more than two DP ports don't need it. (I'm assuming eDP is compatible with DP, if not that would be really stupid).
PermalinkPermalink 01/26/11 @ 19:31

In response to: Debugging display problems

jbarnes [Member]
Zach, ha that's interesting. I can imagine the memory config being responsible for all sorts of weirdness if it was off somehow; your corruption sounds fun :) (I definitely wouldn't have guessed a memory issue right away).
PermalinkPermalink 01/24/11 @ 09:57

Virtuous blogs

December 2017
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Search

Misc

XML Feeds

What is RSS?

Who's Online?

  • Guest Users: 28

powered by b2evolution free blog software