Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
On Tue, 12 May 2009 15:19:34 -0700 Andrew Morton a...@linux-foundation.org wrote: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 12 May 2009 01:40:48 GMT bugzilla-dae...@bugzilla.kernel.org wrote: On my system, the colors are displaying incorrectly when using the Intel framebuffer. For example the Tux penguin logo has a blue background, and when I start X11 with the fbdev drivers, the xterm also has a blue background, when it is set up to have a white background. This does not occur in kernel 2.6.29 -- I can see the Tasmanian devil in a penguin mask (Tuz) just fine and can view images, etc on the framebuffer. The only change to drivers/video/intelfb/ since 2.6.29 was 347486bb108fa6e0fd2753c1be3519d6be2516ed (intelfb: support i854) which added a device ID. Do we think that this regression is due to fbdev changes, or to DRI changes? There were changes to fbdev common code as well. Dean, could you post more info about your system? A good starting point is an output of the dmesg command. Kind regards, Krzysztof -- Dzwonki na komorkê! Sprawdz http://link.interia.pl/f2161 -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM/i915 Kernel Warning
I submitted a patch for the below error a while back... this problem is still present in 2.6.30-rc5. Am I submitting this patch to the right place??? If not, where should I send it? Sorry for troubling you. Thanks in advance, Jonas Jonas Bonn wrote: With 2.6.30-rc4 I get the following warning: WARNING: at fs/sysfs/dir.c:487 sysfs_add_one+0xcf/0xe6() Hardware name: P5K-VM sysfs: cannot create duplicate filename '/devices/pci:00/:00:02.0/drm/ca rd0/card0-VGA-1' Pid: 578, comm: work_for_cpu Not tainted 2.6.30-rc4-jonas #79 Call Trace: [81057fb5] warn_slowpath+0xce/0x102 [814c8b64] ? thread_return+0x41/0xbb [8104b2ae] ? resched_task+0x27/0x6e [81241421] ? idr_get_empty_slot+0x169/0x24d [8124762f] ? string+0x3f/0xa2 [8112cafe] ? sysfs_pathname+0x37/0x3f [8112cafe] ? sysfs_pathname+0x37/0x3f [8112cafe] ? sysfs_pathname+0x37/0x3f [8112cafe] ? sysfs_pathname+0x37/0x3f [8112cbd5] sysfs_add_one+0xcf/0xe6 [8112d200] create_dir+0x58/0x93 [8112d273] sysfs_create_dir+0x38/0x4f [81242457] ? kobject_get+0x1a/0x22 [8124260c] kobject_add_internal+0x131/0x20d [81248676] ? delay_tsc+0x2c/0x60 [812427c0] kobject_add_varg+0x41/0x4e [812428d2] kobject_add+0x89/0x8b [81242776] ? kobject_set_name_vargs+0x4f/0x58 [81242457] ? kobject_get+0x1a/0x22 [812fa80e] device_add+0x144/0x5bc [81241786] ? idr_get_new_above+0x11/0x31 [812420b3] ? kobject_init+0x43/0x83 [812fac9f] device_register+0x19/0x1e [812d0653] drm_sysfs_connector_add+0xb6/0x1a2 [812eb238] intel_sdvo_init+0x3c1/0x5a7 [812d038f] ? drm_sysfs_hotplug_event+0x53/0x5a [812e78a3] intel_modeset_init+0x4c2/0x77b [812dadbe] i915_driver_load+0x931/0x99a [812ce2ae] drm_get_dev+0x333/0x3fc [810525ae] ? default_wake_function+0xd/0xf [81067e98] ? do_work_for_cpu+0x0/0x26 [814bbc14] i915_pci_probe+0x10/0x12 [81259e93] local_pci_probe+0x12/0x16 [81067eab] do_work_for_cpu+0x13/0x26 [8106b168] kthread+0x56/0x83 [8102ac0a] child_rip+0xa/0x20 [8106b112] ? kthread+0x0/0x83 [8102ac00] ? child_rip+0x0/0x20 and kobject_add_internal failed for card0-VGA-1 with -EEXIST, don't try to register things with the same name in the same directory. Pid: 578, comm: work_for_cpu Tainted: GW 2.6.30-rc4-jonas #79 Call Trace: [812421ba] ? kobject_put+0x47/0x4b [812426b6] kobject_add_internal+0x1db/0x20d [81248676] ? delay_tsc+0x2c/0x60 [812427c0] kobject_add_varg+0x41/0x4e [812428d2] kobject_add+0x89/0x8b [81242776] ? kobject_set_name_vargs+0x4f/0x58 [81242457] ? kobject_get+0x1a/0x22 [812fa80e] device_add+0x144/0x5bc [81241786] ? idr_get_new_above+0x11/0x31 [812420b3] ? kobject_init+0x43/0x83 [812fac9f] device_register+0x19/0x1e [812d0653] drm_sysfs_connector_add+0xb6/0x1a2 [812eb238] intel_sdvo_init+0x3c1/0x5a7 [812d038f] ? drm_sysfs_hotplug_event+0x53/0x5a [812e78a3] intel_modeset_init+0x4c2/0x77b [812dadbe] i915_driver_load+0x931/0x99a [812ce2ae] drm_get_dev+0x333/0x3fc [810525ae] ? default_wake_function+0xd/0xf [81067e98] ? do_work_for_cpu+0x0/0x26 [814bbc14] i915_pci_probe+0x10/0x12 [81259e93] local_pci_probe+0x12/0x16 [81067eab] do_work_for_cpu+0x13/0x26 [8106b168] kthread+0x56/0x83 [8102ac0a] child_rip+0xa/0x20 [8106b112] ? kthread+0x0/0x83 [8102ac00] ? child_rip+0x0/0x20 This happens because the type of connector in intel_sdvo_init is intially set to Unknown. The 'type_id' of the connector is thus selected from the ID pool for connectors of type Unknown. When the connector type is subsequently changed, the type_id is wrong as it hasn't been taken from the right pool. The attached patch resolves this by determing the connector type before initializing the connector. It should be noted that the connector_type should not be changed after the connector has been initialized. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Need sample program or tutorial
Bridgman, John wrote: My understanding was that XF86DRIQueryDirectRenderingCapable just asked the X server if *it* was able to support direct rendering on a particular screen, didn't tell you anything about whether the right 3D driver existed or was installed correctly. That would explain to me Jerome's earlier comment that glXIsDirect tells me all I need to know. Not sure what hardware documentation has to do with this; Documentation from source shows one way to achieve a particular goal and usually not what the chip could do to achieve a different goal or the same goal differently. Hence my preference for vendor documentation. Corbin Simpson wrote: The DRM only exposes a few simple ioctls; ... Yes but extremely powerful. They may suffer though from a similar defect as described for documentation from source - I don't know. We're already working on a project called Gallium3D, .. It's already been done with cairo-drm, which created Cairo contexts directly bound to i915 hardware through DRM. So it's certainly possible. I will have a look and also at Cairo Now, if I may, back to my immediate problem. I have a program that runs perfectly when passing False as 4th argument to glXCreateContext. glXIsDirect confirms I got an indirect rendering context. When passing True the call to glXCreateContext succeeds, glXIsDirect returns GL_TRUE but glXMakeCurrent fails. I thought and see confirmation for that thought in some of your comments that that should not happen. Correct ? Any ideas? Anyway, I will go back to the reading room. Thanks for your reactions sofar. Enno -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Need sample program or tutorial
On Thu, 2009-05-14 at 10:35 +0200, Enno Fennema wrote: Now, if I may, back to my immediate problem. It might have been a good idea to start with that in the first place. :) I have a program that runs perfectly when passing False as 4th argument to glXCreateContext. glXIsDirect confirms I got an indirect rendering context. When passing True the call to glXCreateContext succeeds, glXIsDirect returns GL_TRUE but glXMakeCurrent fails. I thought and see confirmation for that thought in some of your comments that that should not happen. Correct ? It depends on the arguments to glXMakeCurrent. E.g. if the drawable is a pixmap, that isn't supported without DRI2. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21582] [radeon-rewrite] crashes server through radeonRefillCurrentDmaRegion
http://bugs.freedesktop.org/show_bug.cgi?id=21582 --- Comment #4 from Maciej Cencora m.cenc...@gmail.com 2009-05-14 05:31:04 PST --- The problem is in radeonRefillCurrentDmaRegion: we call radeon_revalidate_bos which calls radeonFlush which frees rmesa-dma.current (only if some conditions are met) so we end up dereferencing null pointer by radeon_bo_map. There are two solutions: - remove radeon_revalidate_bos from radeonRefillCurrentDmaRegion, - check if rmesa-dma.current is null after calling radeon_revalidate_bos and create new bo if necessary Both solutions proved to be working, unfortunately I don't know which one is the correct one. If Jerome Glisse doesn't know too we probably have to wait for Dave Airlie to decide. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Need sample program or tutorial
Michel Dänzer wrote: It depends on the arguments to glXMakeCurrent. E.g. if the drawable is a pixmap, that isn't supported without DRI2. Good to get on a sidetrack again. You are right. XF86 does appear not to support rendering to GLXPixmaps with a direct context. But I was using an GLXWindow. How come I can succesfully get either a direct or an indirect context but with the latter glXMakeCurrent fails. I am still foxed Enno -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Need sample program or tutorial
Just to add to my mail of a few minutes ago. I had a look at the GLX 1.4 manual and glXMakeCurrent should never return a BadValue error. I am even more foxed Enno -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM/i915 Kernel Warning
On Thu, 14 May 2009 09:47:38 +0200 Jonas Bonn jo...@southpole.se wrote: I submitted a patch for the below error a while back... this problem is still present in 2.6.30-rc5. Am I submitting this patch to the right place??? If not, where should I send it? Sorry for troubling you. Thanks in advance, Ah yeah you should probably send this to intel-...@lists.freedesktop.org and cc e...@anholt.net so he can apply it. Patch looks fine. -- Jesse Barnes, Intel Open Source Technology Center -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21609] [radeon-rewrite] Use correct texture format for RGB textures
http://bugs.freedesktop.org/show_bug.cgi?id=21609 --- Comment #3 from Paulo Dias paulo_c_d...@ig.com.br 2009-05-14 10:25:19 PST --- does this bug fixed the rgba problem with dri2 and kde4/compiz/gtk? because i'm using the latest mesa from glisse (which has this patch) and i'm still having problem with wrong rgb colors with gtk and kde4 apps. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH resend] drm: ignore LVDS on intel graphics systems that lie about having it
On Tue, 2009-05-05 at 10:00 -0400, Jarod Wilson wrote: There are a number of small form factor desktop systems with Intel mobile graphics chips that lie and say they have an LVDS. With kernel mode-setting, this becomes a problem, and makes native resolution boot go haywire -- for example, my Dell Studio Hybrid, hooked to a 1920x1080 display claims to have a 1024x768 LVDS, and the resulting graphical boot on the 1920x1080 display uses only the top left 1024x768, and auto-configured X will end up only 1024x768 as well. With this change, graphical boot and X both do 1920x1080 as expected. Note that we're simply embracing and extending the early bail-out code in place for the Mac Mini here. The xorg intel driver uses pci subsystem device and vendor id for matching, while we're using dmi lookups here. The MSI addition is courtesy of and tested by Bill Nottingham. Signed-off-by: Jarod Wilson ja...@redhat.com Tested-by: Bill Nottingham nott...@redhat.com Looks good, I'm pulling it for 2.6.30. Thanks! -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Add modesetting pageflip ioctl and corresponding drm event
From: Kristian Høgsberg k...@redhat.com
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the screen contents
with hw-guaranteed low latency page flipping.
The ioctl is asynchronous in that it returns immediately and then later
notifies the client by making an event available for reading on the drm fd.
This lets applications add the drm fd to their main loop and handle other
tasks while waiting for the flip to happen. The event includes the time
of the flip, the frame counter and a 64 bit opaque token provided by
user space in the ioctl.
Based on initial work and suggestions from
Jesse Barnes jbar...@virtuousgeek.org and
Jakob Bornecrantz wallbra...@gmail.com.
Signed-off-by: Kristian Høgsberg k...@redhat.com
---
This update addresses a few of the issues brought up by Jakob:
- the u64 user_data field is moved the page flip event
from the drm header struct.
- the implementation of the page flip ioctl is moved to
drm_crtc.h instead of drm_crtc_helper.c
and cleanup in drm_release() is simpler and should clean up
everything (it was missing an unpin before, now we just use the
same code as the normal drm_read() case).
What's still missing is:
- don't block on setting the domain in set_base
- the synchronous version of the ioctl; userspace can
just use the ioctl followed by a read loop.
I'll be updating userspace, but I'm moving slowly on this - I can't get to
that before next week. Fedora 11 blockers and all...
cheers,
Kristian
drivers/gpu/drm/drm_crtc.c | 120 +-
drivers/gpu/drm/drm_crtc_helper.c| 14 +++--
drivers/gpu/drm/drm_drv.c|1 +
drivers/gpu/drm/drm_fops.c | 68 +++-
drivers/gpu/drm/drm_irq.c| 42
drivers/gpu/drm/i915/i915_drv.c |1 +
drivers/gpu/drm/i915/intel_display.c | 27 +---
include/drm/drm.h| 25 +++
include/drm/drmP.h | 32 +
include/drm/drm_crtc.h | 21 ++
include/drm/drm_crtc_helper.h|4 -
include/drm/drm_mode.h | 16 +
12 files changed, 348 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 94a7688..5f63ca0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -352,11 +352,12 @@ EXPORT_SYMBOL(drm_framebuffer_cleanup);
*
* Inits a new object created as base part of an driver crtc object.
*/
-void drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
+void drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, int pipe,
const struct drm_crtc_funcs *funcs)
{
crtc-dev = dev;
crtc-funcs = funcs;
+ crtc-pipe = pipe;
mutex_lock(dev-mode_config.mutex);
drm_mode_object_get(dev, crtc-base, DRM_MODE_OBJECT_CRTC);
@@ -2447,3 +2448,120 @@ out:
mutex_unlock(dev-mode_config.mutex);
return ret;
}
+
+/**
+ * drm_mode_page_flip_ioctl - page flip ioctl
+ * @dev: DRM device
+ * @data: ioctl args
+ * @file_priv: file private data
+ *
+ * The page flip ioctl replaces the current front buffer with a new
+ * one, using the CRTC's set_base function, which should just update
+ * the front buffer base pointer. It's up to set_base to make
+ * sure the update doesn't result in tearing (on some hardware the
+ * base register is double buffered, so this is easy).
+ *
+ * Note that this covers just the simple case of flipping the front
+ * buffer immediately. Interval handling and interlaced modes have to
+ * be handled by userspace, or with new ioctls.
+ */
+int drm_mode_page_flip_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+ struct drm_pending_flip *pending;
+ struct drm_mode_page_flip *flip_data = data;
+ struct drm_mode_object *drm_obj, *fb_obj;
+ struct drm_crtc *crtc;
+ int ret = 0;
+
+ if (!(drm_core_check_feature(dev, DRIVER_MODESET)))
+ return -ENODEV;
+
+ /*
+* Reject unknown flags so future userspace knows what we (don't)
+* support
+*/
+ if (flip_data-flags (~DRM_MODE_PAGE_FLIP_FLAGS_MASK)) {
+ DRM_DEBUG(bad page flip flags\n);
+ return -EINVAL;
+ }
+
+ pending = kzalloc(sizeof *pending, GFP_KERNEL);
+ if (pending == NULL)
+ return -ENOMEM;
+
+ mutex_lock(dev-struct_mutex);
+
+ fb_obj = drm_mode_object_find(dev, flip_data-fb_id,
+ DRM_MODE_OBJECT_FB);
+ if (!fb_obj) {
+ DRM_DEBUG(unknown fb %d\n, flip_data-fb_id);
+
Re: DRI page size problem
On Fri, 2009-05-15 at 14:46 +1000, Benjamin Herrenschmidt wrote: Hi Jesse ! Haven't had much time to investigate the problem I've been talking to you and David about but from what I can see in the code, we're probably hitting this in drm_mmap_locked() in drm_vm.c : /* Check for valid size. */ if (map-size vma-vm_end - vma-vm_start) return -EINVAL; Now, this won't do any good for example if the SAREA is 8K (which I think is about that nowadays) and the machine PAGE_SIZE is 64K. Except that radeon_cp.c does: sareapage = max_t(unsigned long, SAREA_MAX, PAGE_SIZE); ret = drm_addmap(dev, 0, sareapage, _DRM_SHM, _DRM_CONTAINS_LOCK|_DRM_DRIVER, master_priv-sarea); So it should have worked ... hrm I'll dig more. Cheers, Ben. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI page size problem
Hi Jesse ! Haven't had much time to investigate the problem I've been talking to you and David about but from what I can see in the code, we're probably hitting this in drm_mmap_locked() in drm_vm.c : /* Check for valid size. */ if (map-size vma-vm_end - vma-vm_start) return -EINVAL; Now, this won't do any good for example if the SAREA is 8K (which I think is about that nowadays) and the machine PAGE_SIZE is 64K. There is indeed a possible problem of allowing clients to map more than the resource specifically specified in the map, so just removing that test may not be the best approach though. I would suggest maybe bumping the SAREA to be a multiple of the page size for now. I think that should get us going. I'll have a go at a patch on monday unless there's an objection. That won't help for things like MMIO register space that isn't a multiple of the page size but fortunately that won't be hitting my with radeon for now and we can deal with that when we need to. Any objection ? Cheers, Ben. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
