Hi!
I been working on updating the VIA kernel driver to using KMS
and TTM. So this weekend I started to implement a couple of buffer
allocations internally to the driver from the video ram. So the first
buffer I allocated was not the front buffer from the video vram but a
virtual queu
> > Hi!
> >
> > I been working on updating the VIA kernel driver to using KMS
> > and TTM. So this weekend I started to implement a couple of buffer
> > allocations internally to the driver from the video ram. So the first
> > buffer I allocated was not the front buffer from the video vram
> > Thats fine as long as you don't want to do acceleration or object
> > migration between GTT
> > and VRAM type memory. Now I expect when you give out this advice you
>
> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> It's all effectively in the GART with the 'stol
> > Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
> > of POS devices. That chipset only supports monochrome cursors.
>
> As far as I know, the KMS cursor API doesn't really care what type of
> cursors a
> > Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>
> That depends on your libkms for the device. You can allocate a one bit
> deep object if you want. Reading libkms source is probably what you need
> if
> >> > Thats fine as long as you don't want to do acceleration or object
> >> > migration between GTT
> >> > and VRAM type memory. Now I expect when you give out this advice you
> >>
> >> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> >> It's all effectively in the GA
> On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox wrote:
> >> the front buffer. The problem was the buffer offset for the second
> >> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> >> wrong, so does anyone have a idea?
> >
> > I gave up trying to understand TTM (they don't make
> From: Dave Airlie
>
> For the simple KMS driver case we need some more info about argb cursor
> limits and a preferred depth and if shadowed framebuffer access is preferred.
>
> I've only added this for intel/radeon which support the dumb ioctls so far.
>
> I really don't want to expose a tr
> >> Without code to look at we all can start guessing :) my guess is either
> >> you are not using the proper offset field or you are allocating from
> >> different memory pool.
> >
> > http://cgit.freedesktop.org/~jsimmons/drm-openchrome
> >
>
> >From quick glimpse ttm_bo_allocate in via/init_t
> There is a fully functional unichrome DRM on top of TTM, that together with
> the 3D driver in mesa's openchrome branch worked like a charm (even
> outperformed Intel's i965 with identical CPU at the time).
> Problem was that it was not backwards compatible with via's old drm.
>
> It should ser
Hi!
I tried the xf86-video-modesetting driver with the new via KMS
driver. It worked well but I had to turn off the cursor since I haven't
finished the cursor in the kernel driver yet. By default the SWCursor
option is set to false but when I placed that option in my xorg.conf file
it n
> Review, flames highly welcome.
>
> Cheers, Daniel
>
> Daniel Vetter (23):
> drm/sis: track obj->drm_fd relations in the driver
> drm/via: track obj->drm_fd relations in the driver
> drm/sman: kill owner tracking interface functions
> drm/sman: rip out owner tracking
> drm/via: track
> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
> > I'm not sure whether / how you handle the case of hardware render to
> > cursor surfaces on i915, but it seems to me like if a lot of drivers
> > need to implement driver specific "tricks" to meet the semantics of
> > a generi
> > Should I test this set of patches for the VIA driver or wait until you
> > have a second version of this patch?
>
> Testing this on via would be awesome! Iirc I haven't changed anything in
> the via specific patches, but if it's more convenient you can also
> directly test my branch:
>
> ht
> I decided to go all out with the pixel format definitions. Added pretty
> much all of the possible RGB/BGR variations. Just left out ones with
> 16bit components and floats. Also added a whole bunch of YUV formats,
> and 8 bit pseudocolor for good measure.
Thank you for including the pseudocolo
> > >> Testing this on via would be awesome! Iirc I haven't changed anything in
> > >> the via specific patches, but if it's more convenient you can also
> > >> directly test my branch:
> > >>
> > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire
> > >
> > > Okay I tried the patches
> Exactly like the previous patch for sis.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
Same goes for PATCH 01 which I'm missing in my inbox.
> ---
> drivers/gpu/drm/via/via_drv.c | 25 +
> drivers/gpu/d
> These are now unused.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/drm_sman.c | 38 --
> include/drm/drm_sman.h | 19 ---
> 2 files changed, 0 insertions(+), 57 deletions
anymore, we need to
> kill the list_move hack and properly add the item to the file_priv
> list.
>
> Also leave the list_del(&obj->owner_list) in drm_sman_free for the
> moment, it will move to the drivers when sman disappears completely.
>
> Signed-off-by: Daniel Vette
pu/drm/via/via_mm.c | 61
> +++--
> 3 files changed, 49 insertions(+), 15 deletions(-)
Acked-by: James Simmons
> diff --git a/drivers/gpu/drm/via/via_drv.h b/drivers/gpu/drm/via/via_drv.h
> index 9cf87d9..108ea71 100644
> --- a/drivers/gpu/drm/via/via_drv.h
> +++ b/d
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/sis/sis_drv.c |4 +++
> drivers/gpu/drm/sis/sis_drv.h |2 +
> drivers/gpu/drm/sis/sis_mm.c | 60 ++--
> drivers/gpu/drm/via/via_map.c |2 +
>
> No longer used.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/drm_sman.c | 36 ++--
> include/drm/drm_sman.h |5 -
> 2 files changed, 2 insertions(+), 39 deletions(-)
>
> d
> Now that we are again in proper control of owner_list, we need to
> properly list_del it on free.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/via/via_drv.h |5 ++-
> drivers/gpu/drm/via/via_map.c |7
> drivers/gpu/
> Signed-off-by: Daniel Vetter
Can't test on SiS but does nothing to my VIA hardware.
Acked-by: James Simmons
> ---
> drivers/gpu/drm/sis/sis_drv.c |4 -
> drivers/gpu/drm/sis/sis_drv.h |5 +-
> drivers/gpu/drm/sis/sis_mm.c | 137 +++
> No longer used.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/Makefile |2 +-
> drivers/gpu/drm/drm_sman.c | 210
>
> include/drm/drm_sman.h | 151 --
> Chris Wilson rightly complained that this doesn't explain the list_del
> magic going on. New commit msg reads:
>
> To make the transition in a piece-wise and bisectable way possible,
> I've hijacked the ->owner_list from drm_sman. While transitioning, the
> list_add was done by the
> A few things
> - kill reclaim_buffers, it's never ever called because via does not set
> DRIVER_HAVE_DMA
> - inline the idlelock dance into the buffer reclaim logic and make it
> a simple preclose cleanup function
> - directly call the the dma_quiescent function and kill the needless
> if
> Hi!
>
> I'm not whether any drivers are still using the AGP backend?
Actually the openchrome projects KMS kernel uses a AGP backend.
> Calling unpopulate / (previous clear) each time unbind is done should be quite
> inefficient with that one, as AGP sets up its own data structures and copies
> Hi Dave,
>
> I've failed to correctly fix the via hang in the reclaim buffers rework
> till now, so I'm only submitting the drm_sman removal of my drm cruft
> removal series.
Last attempt at your branch still had problem. Start I didn't have time
track down the exact issue. I'm cloning the be
Hi!
I updated the openchrome tree and while testing on the AGP system
discovered some interesting problems with the new TTM changes. The
problems center around the ttm_tt_[un]populate which I modeled after the
radeon and nouveau driver.
First problem I noticed was on a AGP sys
> > > Hi Dave,
> > >
> > > I've failed to correctly fix the via hang in the reclaim buffers rework
> > > till now, so I'm only submitting the drm_sman removal of my drm cruft
> > > removal series.
> >
> > Last attempt at your branch still had problem. Start I didn't have time
> > track down the
> > Hi!
> >
> > I updated the openchrome tree and while testing on the AGP system
> > discovered some interesting problems with the new TTM changes. The
> > problems center around the ttm_tt_[un]populate which I modeled after the
> > radeon and nouveau driver.
> > First problem I not
> > > > Last attempt at your branch still had problem. Start I didn't have time
> > > > track down the exact issue. I'm cloning the below branch and will test
> > > > it.
> > > > Thanks for cleanup.
> > >
> > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've
> > > repo
> Attached is patch to fix this, so sorry about that, i must have lost my
> agp change along the way when working on the patchset. This patch is not
> extensively tested, i will do more testing tomorrow on more gpu, might
> even found an nvidia agp i can try. Again sorry for breaking this.
Thanks
> >> Attached is patch to fix this, so sorry about that, i must have lost my
> >> agp change along the way when working on the patchset. This patch is not
> >> extensively tested, i will do more testing tomorrow on more gpu, might
> >> even found an nvidia agp i can try. Again sorry for breaking t
> >> You can achieve what you want by either adding a new domain so you would
> >> have
> >> system, vram, agp, pcidma and object can be bound to one and only one. Or
> >> you
> >> can hack your own agp ttm backend that could bind bo to agp or pci or
> >> both at the same time depending on what
> > Imo we should ditch this - fb accel doesn't belong into the kernel. Even
> > on hw that still has a blitter for easy 2d accel without a complete 3d
> > state setup necessary, it's not worth it. Chris Wilson from our team once
> > played around with implementing fb accel in the kernel (i915 hw
> > Ensuring that nothing prevents the switch to fbcon and displaying the
> > panic message is the reason why we haven't felt inclined to accelerate
> > fbcon - it just gets messy for no real gain.
>
> and when doing 2d accel on a 3d core.. it basically amounts to
> putting a shader compiler in
Enable after a resolution change reload the cursor image.
Signed-off-by: James Simmons
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 7fa933a..8a49103 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -361,11 +361,9 @@ drmmode_set_mode_major(xf86CrtcPtr crtc
This patch replaces drmmode_load_palette with a very generic function
that removes the need of drmmode_crtc_private_rec to carry around
color indexes. Also have the xorg driver actually call
the xf86HandleColormaps function.
Signed-off-by: James Simmons
diff --git a/src/driver.c b/src
> The fb_videomode structure stores the front porch and back porch in the
> right_margin and left_margin fields respectively. right_margin should
> thus be computed with hsync_start - hdisplay, and left_margin with
> htotal - hsync_end. The same holds for the vertical direction.
>
>Active
> as a headsup, if you are basing a tree on mine, please use
> drm-core-next not drm-next itself as a basis for your tree.
>
> At the moment they've diverged as I've put the UDL kms driver into
> drm-next but not drm-core-next as it needs an external fbdev patch to
> work.
Is this temporary?
___
Hello!!
This last year the Openchrome support for the VIA chipsets has
come along way from being in a state of decay. The plan is to release
a Xorg driver June 1 that will have support for the KMS as well as UMS.
The goal is to have this xorg driver out in the wild before the kernel
side
led on this spinlock.
Signed-off-by: Márton Németh
Signed-off-by: James Simmons
diff --git a/drivers/gpu/drm/via/via_map.c b/drivers/gpu/drm/via/via_map.c
index 1f18225..240bc49 100644
--- a/drivers/gpu/drm/via/via_map.c
+++ b/drivers/gpu/drm/via/via_map.c
@@ -100,12 +100,10 @@ int via_driver_lo
> wrote:
> > Am Dienstag, 30. April 2013, 06:06:22 schrieb Dave Airlie:
> >> On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr
> >> wrote:
> >> > Hi James,
> >> >
> >> > Linus recently released Kernel 3.9, merge window for Kernel 3.10 has
> >> > been opened, and the question is whether drm-ope
> > Dave what is the best way to push this code? I am in no rush so
> > I like to do it the right way. We have scattered history in the external
> > tree but I would not lose sleep over its lost. I could just post pieces
> > of the code to this list for review. One choice is after all the c
Hello
Here is the first run at inspection of the VIA openchrome dri
driver. Now that the Xorg driver has been out over a year with KMS support
most people should be able to use this feature. The driver is totaly
complete but we wanted to merge it so people with newer hardware that has
commit 1fcf23d361375645d586756d126b436796ba4fba
Author: James Simmons
Date: Sat Jun 8 09:31:57 2013 -0400
via: New KMS ioctls and hardware to support.
Add new VIA pci ids to support newer hardware. Cleanup userspace
api structs to remove kernel types and add the new KMS
commit f0be3523498cd2422d95af1e5e47f51e099f90e4
Author: James Simmons
Date: Thu Jun 6 18:57:00 2013 -0400
via: register setting helpers
The code in the crtc_hw was written to handle to cases of
programming the registers on the graphics card. Basic
routines of programming
commit 30a9dda2deeebcf611cbeaffb38f0f94c708a976
Author: James Simmons
Date: Thu Jun 6 20:28:33 2013 -0400
via: fence implementation
For each buffer object we create a fence in order to know what
its state is. A fence notifies us when a object is consumed by
the command
commit 6e79030fb92d3461b4a962630245d93944d5d349
Author: James Simmons
Date: Fri Jun 7 20:17:06 2013 -0400
via: ttm pcie dma bo_driver handling
Newer VIA hardware has moved from AGP to more modern PCIe
based hardware. The TTM layer provides support for AGP but
drm drivers
commit fa8599a207fbd0b4ffaa8c6961d34797f615ed7d
Author: James Simmons
Date: Fri Jun 7 19:58:14 2013 -0400
via: ttm bo driver implementation
The openchrome project decided to use the TTM api as the backend to
support GEM. The core needed to support TTM is struct ttm_bo_driver
commit 5ec2cdc6f99549122329253b1c4d1a04193b81d0
Author: James Simmons
Date: Sat Jun 8 07:59:56 2013 -0400
via: TTM and GEM memory handling
TTM buffer object life cycle and state handling is done in init_ttm.c.
The VIA GEM implemenation is a simple wrapper around the TTM layer
commit a1296bc36bbc68963ef0294e94bef69ddb998c9a
Author: James Simmons
Date: Sat Jun 8 08:53:44 2013 -0400
via: i2c handling
In order to support EDID retrieval and the via camera on the XO data
much be collected over the i2c buses. We use the i2c layer developed
by the
commit 761567d6dd4ec80dbc39052ac74edf7626922f55
Author: James Simmons
Date: Sat Jun 8 09:39:04 2013 -0400
via: Hardware initalization/power management functions.
This code handles setting the inital state of the 2D,3D and MPEG engine
as well as our pcie gart tables. The code
commit 86edf1f84ab36213c3bd3a6deb9c0811c7458b2c
Author: James Simmons
Date: Sat Jun 8 09:57:49 2013 -0400
via: Our implementation of KMS outputs and crtc
The header file defines via_crtc, via_connector, and via_encoder. Our
via_connector extents drm_connector by including the
commit 4ed0199a92b71506100240b625da173ef7afaf4c
Author: James Simmons
Date: Sat Jun 8 10:57:59 2013 -0400
via: VIA clock handling
The routines that generate the PLL values to program the registers with.
Here the VCLK is programmed to properly set the video mode
commit ab2beb77d5889b18112ee02c381e817eebbdccff
Author: James Simmons
Date: Sat Jun 8 11:02:43 2013 -0400
via: IGA (CRTC) handling
Routines to program all things crtc related. This covers gamma tables,
cursors
and of course resolution setting.
Signed-Off-by: James
commit 991c37448ff8403727f12af331eb164eb5ed4048
Author: James Simmons
Date: Sat Jun 8 11:12:36 2013 -0400
via: VIA kms frame buffer support
Each version of hardware has a unquie way to detect the amount of
video ram. We detect the amount for all known device. Here we
commit 9549976c231b676c2c8e70fd6979115c1c8ed747
Author: James Simmons
Date: Sat Jun 8 12:02:59 2013 -0400
via: VGA analog support
Implement the encoder and connector for VGA analog displays.
Signed-Off-by: James Simmons
diff --git a/drivers/gpu/drm/via/via_analog.c b
commit 1c886b4f35ec239f7787a6a4db10ecc80b3c9824
Author: James Simmons
Date: Sat Jun 8 12:04:31 2013 -0400
via: LVDS support
Implement the encoder and connector for LVDS lcd type displays.
Signed-Off-by: James Simmons
diff --git a/drivers/gpu/drm/via/via_lvds.c b
commit a2e0f8fc0ded9788815cdc68d3acded9f43116b4
Author: James Simmons
Date: Sat Jun 8 12:08:57 2013 -0400
via: TMDS support
Implement the encoder and connector for TMDS devices. This handles the case
of DVI port devices not based on an HDMI encoder. This is basic support will
commit 467eefb4a02972c5f9747ddaa7d8d582fb15a759
Author: James Simmons
Date: Sat Jun 8 12:13:25 2013 -0400
via: HDMI/DVI-D support
Implement the encoder and connector for HDMI/DVI-D displays.
Signed-Off-by: James Simmons
diff --git a/drivers/gpu/drm/via/via_hdmi.c b
commit 589665935a7ec7c29103c9ea4eb1d0ffc4b918d5
Author: James Simmons
Date: Sat Jun 8 12:15:30 2013 -0400
via: New GEM/TTM kms ioctls
New ioctls to allow userland to allocate TTM/GEM buffer objects. Obsolete
UMS ioctls.
Signed-Off-by: James Simmons
diff --git a
commit adafa472a5426e6e6ce513fbbad77b0aef0005a3
Author: James Simmons
Date: Sat Jun 8 12:24:50 2013 -0400
via: IRQ code updates
Expand the IRQ code to handle more than just the DMA and MPEG engines.
Now we handle hotplug as well and improve vblank support on both crtcs
commit f4101ca539b83c824747d657bbdc28834276fea8
Author: James Simmons
Date: Sat Jun 8 12:28:13 2013 -0400
via: Piece all the TTM/KMS changes together.
This updates the core VIA drm driver to support KMS/TTM/GEM. This includes
setting up the graphics cards resources and
> > commit 1fcf23d361375645d586756d126b436796ba4fba
> > Author: James Simmons
> > Date: Sat Jun 8 09:31:57 2013 -0400
> >
> > via: New KMS ioctls and hardware to support.
> >
> > Add new VIA pci ids to support newer hardware. Cleanup userspace
> Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
> > Okay drm-next is pretty big, possibly the biggest ever.
> >
> > Outstanding things I know about, and will merge, if they arrive soon:
> > exynos -next
> > nouveau -next
> >
> > Big things I've merged:
> > new rcar driver
> > intel ne
Add new TTM/GEM ioctls to be able to manage buffer regions from
different domains. Included in the new ioctls is the ability to
query hardware information.
Signed-Off-by: James Simmons
---
include/uapi/drm/via_drm.h | 115
1 file changed, 95
Looking to work on the 3Dfx KMS driver I discovered that it is very
difficult to find a motherboard that supports AGP of 3.3V. So I discovered
that the only 3Dfx card that supports this is the 3dfx Voodoo 4 4500 AGP
Card which also is difficult to find. Does anyone have this card to send
to me
->accel_flags to FB_ACCELF_TEXT.
Signed-off-by: James Simmons
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d2849e4..aa37711 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -985,6 +985,8 @@ void drm_fb_helper_fill_fix(str
> On Wed, Nov 10, 2010 at 7:45 PM, James Simmons wrote:
> > Looking to work on the 3Dfx KMS driver I discovered that it is very
> > difficult to find a motherboard that supports AGP of 3.3V. So I discovered
> > that the only 3Dfx card that supports this is the 3dfx Voodo
.
Signed-off-by: James Simmons
---
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d2849e4..aa37711 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -985,6 +985,8 @@ void drm_fb_helper_fill_fix(struct fb_info *info, uint32_t
fields. I'm hoping some day fix->smem* could be set here :-)
Signed-off-by: James Simmons
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5c4f9b9..0307d60 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -607,6 +607,25
Hi!
So I recently got my new motherboard with a AGP port for continued
development of 3Dfx KMS. Well this board comes with a built in VIA
based IGP. Well that chipset is poorly supported so I started to work on
the via drm driver. Currently I'm porting it to the TTM infrastructure.
Hi!
The OpenChrome project is now experimenting with a move over to
the new TTM/GEM and KMS apis. A xorg tree has just been started to support
KMS and UMS (svn http://svn.openchrome.org/svn/branches/openchrome-kms). I
also have changes on the kernel side. Those changes need a ho
to bisect?
>
> dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
> commit dfe63bb0ad9810db13aab0058caba97866e0a681
> Author: James Simmons
> Date: Thu Dec 23 16:40:37 2010 +
>
> drm: Update fbdev fb_fix_screeninfo
>
>
> Reverting this on top of todays git a
> Am 12.01.2011 13:49, schrieb James Simmons:
> > I see the problem. Nouveau for some hardware does a accelerated
> > clearing of the screen before we register the framebuffer. The above patch
> > does fix a real issue so please don't revert it. Can you try this pa
of TRAP messages. (see below).
> >>> X11 seems to work fine though...
> >>
> >> Can you try to bisect?
> >
> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
> > Author: James Simmons
>
> >>> I tested the revert: the boot screen did change the resolution
> >>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
> >>
> >> Try my most recent patch. Where does it hang at? Any logs?
> >>
> >
> > With your patch, I can boot the system. But nouveau is not loaded.
> > d
> IOW, I'm inclined to just do the revert. The "fix" clearly breaks
> things, and now you're adding random parts of the function back rather
> than just calling the "fill_fix()" function like things used to. Why?
Its not the final patch. I'm trying to get feedback on what broke exactly.
> The co
> Am 12.01.2011 14:45, schrieb James Simmons:
> >> I tested the revert: the boot screen did change the resolution
> >> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
> >
> > Try my most recent patch. Where does it hang at? Any logs?
>
> > > With your patch, I can boot the system. But nouveau is not loaded.
> > > dmesg attached.
> > >
> >
> > Forget to mention: the revert makes first steps of boot look the same
> > (change the resolution of the text)
> > but with your patch, I see a big ugly ununtu logo, (I think that is
> > be
On Thu, 13 Jan 2011, Anca Emanuel wrote:
> On Thu, Jan 13, 2011 at 7:55 PM, James Simmons wrote:
> >
> >> > > With your patch, I can boot the system. But nouveau is not loaded.
> >> > > dmesg attached.
> >> > >
> >> >
> >&
> > Just as I thought. Even this breaks the nouveau driver.
> >
> > Could you now add also in the drm_fb_helper_fill_fix function
> >
> > DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch,
> > fb_helper->fb->depth);
> >
> > I have a feeling the values are not right. Thanks.
> >
>
> P
driver. This patch fixes i915 with libkms and builds modeprint for test
with other drivers besides i915. It is against libdrm trunk.
Signed-off-by: James Simmons
diff --git a/libkms/linux.c b/libkms/linux.c
index 02182d3..bc422cc 100644
--- a/libkms/linux.c
+++ b/libkms/linux.c
@@ -101,7 +101,7
> I was looking at the radeon support state in libkms and I found out the
> following patch was proposed back in September, but never commented nor
> merged. The patch was submitted by nobled.
>
> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html
>
> I applied it on the
> This adds an initial framework to plug USB graphics devices
> into the drm/kms subsystem.
>
> I've started writing a displaylink driver using this interface.
I own this hardware. Do you have early drivers that I could test.
I assume also you will be cleaning up the edid code since it is very
> I'm still in the learning-as-I-go phase here, so definitely not ready
> to propose a solution, but it does seem to me like there is room for
> some sort of kms-helper library here to handle more of the boilerplate
> xf86-video-* stuff.. I guess I'll have a better picture once I have a
> chance
> On Wed, Feb 9, 2011 at 6:49 AM, James Simmons wrote:
> >
> >> I was looking at the radeon support state in libkms and I found out the
> >> following patch was proposed back in September, but never commented nor
> >> merged. The patch was
> > But while I'm here, is there any advice anywhere for getting patches
> > noticed a little... sooner? 'Cause I have a whole bunch of *other*
> > months-old mesa-dev patches nobody's committed yet.
>
> Poke us more, sorry sometimes we are just bussy with work...
Awesome. Now I know who to send
> More generic approach below - it should work for all drm drivers.
> Unfortunately vga16fb handoff has 2 other issues:
> - It can be compiled as module, so it can be loaded after KMS driver (and
> nothing prevents it right now)
> - vga16fb registration error path is iounmapping memory which was
> On Fri, 9 Apr 2010 15:10:50 -0700
> Jesse Barnes wrote:
>
> > This set of 3 patches makes it a little more likely we'll get panic
> > output onto the screen even when X is running, assuming a KMS enabled
> > stack anyway.
> >
> > It gets me from a blank or very sparsely populated black screen
> > Apologies for such an unspecific description, and for what almost seems
> > like a support request for MythTV. I wouldn't post here if I were not
> > 100% sure it must be related with the recent drm changes.
>
> Note that the DRM APIs are intended for use by userspace components of
> graphics
Sorry I have been away. It looks like the drm-fbdev-fix branch has not
been merged and it has been abandoned. I tested it on both my setups at
home and it worked very well. Will this branch be merged or worked on
more?
___
dri-devel mailing list
dri-
> > Sorry I have been away. It looks like the drm-fbdev-fix branch has not
> > been merged and it has been abandoned. I tested it on both my setups at
> > home and it worked very well. Will this branch be merged or worked on
> > more?
>
> It should have all been merged into Linus, probably not wi
Now that I'm adding in TTM support to my 3Dfx driver I have a questions.
First I noticed in almost every driver for ttm initialization that two
struct ttm_global_reference global_ref are allocated. One for TTM_GLOBAL_TTM_MEM
and one for TTM_GLOBAL_TTM_BO. For a graphics card with only VRAM
This patch uses the much lighter mode_set_base instead of calling a full
mode set. Tested on a i915 netbook. Patch should be against drm-core-next.
Signed-By: James Simmons
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 7196620..99889e3 100644
--- a
Expand the crtc_gamma_set function to accept a starting offset. The
reason for this is to eventually use this function for setcolreg from
drm_fb_helper.c. The fbdev colormap function can start at any offset in
the color map.
Signed-by: James Simmons
diff --git a/drivers/gpu/drm/drm_crtc.c b
fb_info to
determine the most optimized path to scroll/draw etc. If pan_display fails
the fbcon code adapts to that change.
> > Signed-By: James Simmons
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 7196620..9988
1 - 100 of 202 matches
Mail list logo
