Hi
I thought it's better to ask this question here again as it is easier to comment via mail.
I tried writing a simple kms modesetting program. I have written it similar to: http://virtuousgeek.org/blog/index.php/jbarnes?blog=2&title=writing_stan... and wayland compositor-drm.c and modetest.c in libdrm/tests
My problem is, the program compiles and runs fine, however, the framebuffer is only displayed on the left quarter of the screen. The vertical size is perfect but the horizontal size is just the left quarter. I've double checked all the drm parameters and they are equal to the ones in modetest.c and compositor-drm.c.
./modetest runs fine and also reports only a single mode and encoder for my connector so I cannot choose the wrong mode, either.
The code is here: https://gist.github.com/1364994 It should compile fine with: gcc -o bin file.c `pkg-config --cflags --libs egl gbm gl`
I would be glad if someone could run this or look over the code.
Regards David
On Mon, 14 Nov 2011 21:25:56 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
Hi
I thought it's better to ask this question here again as it is easier to comment via mail.
I tried writing a simple kms modesetting program. I have written it similar to: http://virtuousgeek.org/blog/index.php/jbarnes?blog=2&title=writing_stan... and wayland compositor-drm.c and modetest.c in libdrm/tests
My problem is, the program compiles and runs fine, however, the framebuffer is only displayed on the left quarter of the screen. The vertical size is perfect but the horizontal size is just the left quarter. I've double checked all the drm parameters and they are equal to the ones in modetest.c and compositor-drm.c.
./modetest runs fine and also reports only a single mode and encoder for my connector so I cannot choose the wrong mode, either.
The code is here: https://gist.github.com/1364994 It should compile fine with: gcc -o bin file.c `pkg-config --cflags --libs egl gbm gl`
I would be glad if someone could run this or look over the code.
Hm I get a full white screen with a gray triangle in the lower right hand corner. I had to modify the resolution the test was searching for to 1920x1200 instead of 1024x600 since I tested on a DP attached monitor, and fix the connector id, but other than that it seemed to work fine.
On Mon, Nov 14, 2011 at 9:38 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Mon, 14 Nov 2011 21:25:56 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
Hi
I thought it's better to ask this question here again as it is easier to comment via mail.
I tried writing a simple kms modesetting program. I have written it similar to: http://virtuousgeek.org/blog/index.php/jbarnes?blog=2&title=writing_stan... and wayland compositor-drm.c and modetest.c in libdrm/tests
My problem is, the program compiles and runs fine, however, the framebuffer is only displayed on the left quarter of the screen. The vertical size is perfect but the horizontal size is just the left quarter. I've double checked all the drm parameters and they are equal to the ones in modetest.c and compositor-drm.c.
./modetest runs fine and also reports only a single mode and encoder for my connector so I cannot choose the wrong mode, either.
The code is here: https://gist.github.com/1364994 It should compile fine with: gcc -o bin file.c `pkg-config --cflags --libs egl gbm gl`
I would be glad if someone could run this or look over the code.
Hm I get a full white screen with a gray triangle in the lower right hand corner.
Yes, thats what should be displayed.
I had to modify the resolution the test was searching for to 1920x1200 instead of 1024x600 since I tested on a DP attached monitor, and fix the connector id, but other than that it seemed to work fine.
Thanks for testing. At least my code seems right now, but I still cannot get it to work on my machine. The output of modetest is: https://gist.github.com/1365083
There is only one connected connector+encoder+mode so I don't know where the problem exactly is. Are there any debug options? Is it possible to query the EGLImage for width/height?
-- Jesse Barnes, Intel Open Source Technology Center
Cheers David
On Mon, 14 Nov 2011 21:47:09 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
I had to modify the resolution the test was searching for to 1920x1200 instead of 1024x600 since I tested on a DP attached monitor, and fix the connector id, but other than that it seemed to work fine.
Thanks for testing. At least my code seems right now, but I still cannot get it to work on my machine. The output of modetest is: https://gist.github.com/1365083
There is only one connected connector+encoder+mode so I don't know where the problem exactly is. Are there any debug options? Is it possible to query the EGLImage for width/height?
Ok maybe the gen3 vs gen4 EGL image code isn't calculating the width/stride correctly somewhere then. You'd have to walk through the gbm_dri2.c and egl_dri2.c code and see where the width is going off into the weeds.
On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Mon, 14 Nov 2011 21:47:09 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
I had to modify the resolution the test was searching for to 1920x1200 instead of 1024x600 since I tested on a DP attached monitor, and fix the connector id, but other than that it seemed to work fine.
Thanks for testing. At least my code seems right now, but I still cannot get it to work on my machine. The output of modetest is: https://gist.github.com/1365083
There is only one connected connector+encoder+mode so I don't know where the problem exactly is. Are there any debug options? Is it possible to query the EGLImage for width/height?
Ok maybe the gen3 vs gen4 EGL image code isn't calculating the width/stride correctly somewhere then. You'd have to walk through the gbm_dri2.c and egl_dri2.c code and see where the width is going off into the weeds.
Could be, I know I've run Wayland on Pineview though, so that works at least. David, did you try eglkms from mesa demos?
http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c
Kristian
2011/11/15 Kristian Høgsberg krh@bitplanet.net:
On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Mon, 14 Nov 2011 21:47:09 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
I had to modify the resolution the test was searching for to 1920x1200 instead of 1024x600 since I tested on a DP attached monitor, and fix the connector id, but other than that it seemed to work fine.
Thanks for testing. At least my code seems right now, but I still cannot get it to work on my machine. The output of modetest is: https://gist.github.com/1365083
There is only one connected connector+encoder+mode so I don't know where the problem exactly is. Are there any debug options? Is it possible to query the EGLImage for width/height?
Ok maybe the gen3 vs gen4 EGL image code isn't calculating the width/stride correctly somewhere then. You'd have to walk through the gbm_dri2.c and egl_dri2.c code and see where the width is going off into the weeds.
Could be, I know I've run Wayland on Pineview though, so that works at least. David, did you try eglkms from mesa demos?
http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c
I tried it now. I get a black screen and in the left quarter there is one white triangle which fades to black. But again, the right 3/4 of the screen are black.
Kristian
I will try to debug my mesa package but this will probably take some time. If someone has an idea how to find the bug faster, just tell me ;)
Regards David
2011/11/15 David Herrmann dh.herrmann@googlemail.com:
2011/11/15 Kristian Høgsberg krh@bitplanet.net:
On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Mon, 14 Nov 2011 21:47:09 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
I had to modify the resolution the test was searching for to 1920x1200 instead of 1024x600 since I tested on a DP attached monitor, and fix the connector id, but other than that it seemed to work fine.
Thanks for testing. At least my code seems right now, but I still cannot get it to work on my machine. The output of modetest is: https://gist.github.com/1365083
There is only one connected connector+encoder+mode so I don't know where the problem exactly is. Are there any debug options? Is it possible to query the EGLImage for width/height?
Ok maybe the gen3 vs gen4 EGL image code isn't calculating the width/stride correctly somewhere then. You'd have to walk through the gbm_dri2.c and egl_dri2.c code and see where the width is going off into the weeds.
Could be, I know I've run Wayland on Pineview though, so that works at least. David, did you try eglkms from mesa demos?
http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c
I tried it now. I get a black screen and in the left quarter there is one white triangle which fades to black. But again, the right 3/4 of the screen are black.
Kristian
I will try to debug my mesa package but this will probably take some time. If someone has an idea how to find the bug faster, just tell me ;)
It's all very odd. The gbm allocation ends up in intel_create_image in src/mesa/drivers/dri/intel/intel_screen.c, so you can try to compare the stride, width and height there with what modetest uses.
Kristiain
2011/11/15 Kristian Høgsberg krh@bitplanet.net:
2011/11/15 David Herrmann dh.herrmann@googlemail.com:
2011/11/15 Kristian Høgsberg krh@bitplanet.net:
On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Mon, 14 Nov 2011 21:47:09 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
I had to modify the resolution the test was searching for to 1920x1200 instead of 1024x600 since I tested on a DP attached monitor, and fix the connector id, but other than that it seemed to work fine.
Thanks for testing. At least my code seems right now, but I still cannot get it to work on my machine. The output of modetest is: https://gist.github.com/1365083
There is only one connected connector+encoder+mode so I don't know where the problem exactly is. Are there any debug options? Is it possible to query the EGLImage for width/height?
Ok maybe the gen3 vs gen4 EGL image code isn't calculating the width/stride correctly somewhere then. You'd have to walk through the gbm_dri2.c and egl_dri2.c code and see where the width is going off into the weeds.
Could be, I know I've run Wayland on Pineview though, so that works at least. David, did you try eglkms from mesa demos?
http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c
I tried it now. I get a black screen and in the left quarter there is one white triangle which fades to black. But again, the right 3/4 of the screen are black.
Kristian
I will try to debug my mesa package but this will probably take some time. If someone has an idea how to find the bug faster, just tell me ;)
It's all very odd. The gbm allocation ends up in intel_create_image in src/mesa/drivers/dri/intel/intel_screen.c, so you can try to compare the stride, width and height there with what modetest uses.
I just recompiled with newest git revision and I cannot reproduce the bug anymore. I cannot tell what fixed it as I recompiled with other configure options. Previously I used --disable-glx-tls and --enable-gallium-drivers=i915. Now I use --enable-glx-tls and no i915 in gallium but only --with-dri-drivers=i915. My laptop takes about 30min to compile mesa so I haven't tracked it down, yet.
Kristiain
Regards David
On Fri, 18 Nov 2011 22:35:13 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
2011/11/15 Kristian Høgsberg krh@bitplanet.net:
2011/11/15 David Herrmann dh.herrmann@googlemail.com:
2011/11/15 Kristian Høgsberg krh@bitplanet.net:
On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Mon, 14 Nov 2011 21:47:09 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
> I had to modify the resolution the test was searching for > to 1920x1200 instead of 1024x600 since I tested on a DP attached > monitor, and fix the connector id, but other than that it seemed to > work fine.
Thanks for testing. At least my code seems right now, but I still cannot get it to work on my machine. The output of modetest is: https://gist.github.com/1365083
There is only one connected connector+encoder+mode so I don't know where the problem exactly is. Are there any debug options? Is it possible to query the EGLImage for width/height?
Ok maybe the gen3 vs gen4 EGL image code isn't calculating the width/stride correctly somewhere then. You'd have to walk through the gbm_dri2.c and egl_dri2.c code and see where the width is going off into the weeds.
Could be, I know I've run Wayland on Pineview though, so that works at least. David, did you try eglkms from mesa demos?
http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c
I tried it now. I get a black screen and in the left quarter there is one white triangle which fades to black. But again, the right 3/4 of the screen are black.
Kristian
I will try to debug my mesa package but this will probably take some time. If someone has an idea how to find the bug faster, just tell me ;)
It's all very odd. The gbm allocation ends up in intel_create_image in src/mesa/drivers/dri/intel/intel_screen.c, so you can try to compare the stride, width and height there with what modetest uses.
I just recompiled with newest git revision and I cannot reproduce the bug anymore. I cannot tell what fixed it as I recompiled with other configure options. Previously I used --disable-glx-tls and --enable-gallium-drivers=i915. Now I use --enable-glx-tls and no i915 in gallium but only --with-dri-drivers=i915. My laptop takes about 30min to compile mesa so I haven't tracked it down, yet.
Ah it's probably gallium vs classic then. We don't support the gallium driver at all, so I'm not sure what state it's in.
On Fri, Nov 18, 2011 at 10:41 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Fri, 18 Nov 2011 22:35:13 +0100 David Herrmann dh.herrmann@googlemail.com wrote:
2011/11/15 Kristian Høgsberg krh@bitplanet.net:
2011/11/15 David Herrmann dh.herrmann@googlemail.com:
2011/11/15 Kristian Høgsberg krh@bitplanet.net:
On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Mon, 14 Nov 2011 21:47:09 +0100 David Herrmann dh.herrmann@googlemail.com wrote: > > I had to modify the resolution the test was searching for > > to 1920x1200 instead of 1024x600 since I tested on a DP attached > > monitor, and fix the connector id, but other than that it seemed to > > work fine. > > Thanks for testing. At least my code seems right now, but I still > cannot get it to work on my machine. The output of modetest is: > https://gist.github.com/1365083 > > There is only one connected connector+encoder+mode so I don't know > where the problem exactly is. Are there any debug options? Is it > possible to query the EGLImage for width/height?
Ok maybe the gen3 vs gen4 EGL image code isn't calculating the width/stride correctly somewhere then. You'd have to walk through the gbm_dri2.c and egl_dri2.c code and see where the width is going off into the weeds.
Could be, I know I've run Wayland on Pineview though, so that works at least. David, did you try eglkms from mesa demos?
http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c
I tried it now. I get a black screen and in the left quarter there is one white triangle which fades to black. But again, the right 3/4 of the screen are black.
Kristian
I will try to debug my mesa package but this will probably take some time. If someone has an idea how to find the bug faster, just tell me ;)
It's all very odd. The gbm allocation ends up in intel_create_image in src/mesa/drivers/dri/intel/intel_screen.c, so you can try to compare the stride, width and height there with what modetest uses.
I just recompiled with newest git revision and I cannot reproduce the bug anymore. I cannot tell what fixed it as I recompiled with other configure options. Previously I used --disable-glx-tls and --enable-gallium-drivers=i915. Now I use --enable-glx-tls and no i915 in gallium but only --with-dri-drivers=i915. My laptop takes about 30min to compile mesa so I haven't tracked it down, yet.
Ah it's probably gallium vs classic then. We don't support the gallium driver at all, so I'm not sure what state it's in.
I recompiled it with the gallium driver. The problem definitely is the gallium driver. However, if it is unsupported, I will not investigate further.
Thanks for your responses.
-- Jesse Barnes, Intel Open Source Technology Center
Regards David
dri-devel@lists.freedesktop.org
-
David Herrmann -
Jesse Barnes -
Kristian Høgsberg