fields. I'm hoping some day fix-smem* could be set here :-)
Signed-off-by: James Simmons jsimm...@infradead.org
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
Whoo! I'll put this up on k.org as soon as I can get it working.
The only problem is it will not work with X running with the tdfx xorg
driver :-( The driver will need more love as well.
~ C.
On Wed, Jul 14, 2010 at 12:01 PM, James Simmons jsimm...@infradead.org
wrote:
On Wed, Jun
the support. It enables this for KMS drivers.
Signed-off-by: Dave Airlie airl...@redhat.com
I really like the fact that the console driver has a flag to turn this on
or off.
Signed-off-by: James Simmons jsimm...@infradead.org
---
drivers/char/vt.c | 13
to do it.
Signed-off-by: Dave Airlie airl...@redhat.com
Cc: sta...@kernel.org
---
include/linux/fb.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Signed-off-by: James Simmons jsimm...@infradead.org
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 907ace3
I'm working on modesetting, and I'm kind of unsure how to proceed.
My repository is here (ignore all the commit dates):
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary
I also did one for the 3Dfx drm driver. Just as a note make sure that your
glint driver works with
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?
don't need a fb_setcolreg hook. Please apply.
Signed-off-by: James Simmons jsimm...@infradead.org
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3757a25..64a207c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -594,36
The fb_ops can only be called from fbcon or the fbdev userland
interface.
The fbcon calls should only happen when the VC is in KD_TEXT mode. Now
with the DRM backend we have the advantage of creating a mapping
seperate
from the console mapping. A fb_open/fb_close
The fb_ops can only be called from fbcon or the fbdev userland interface.
The fbcon calls should only happen when the VC is in KD_TEXT mode. Now
with the DRM backend we have the advantage of creating a mapping seperate
from the console mapping. A fb_open/fb_close could be used to
Searching the TTM code I couldn't find the handle code so easily. I see
that the vmwgfx driver provides a example of using ttm.
So handles are purely a userspace interface, in-kernel we don't use handles
for buffer management, the vmwgfx TTM interface has
vmw_user_surface_lookup_handle
The big issue we have with resizing the buffer is userspace mmaps of the
fbdev
device, and invalidation.
Previous thread of unresolvedness is here.
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html
Actually AFAIR (and reading through it again seems to confirm
Can't it print the oops on whatever is currently displayed?
It need not be a dedicated buffer as long as there is always some buffer.
But perhaps this is more complex than that.
Yes it is very complex. Reading the code and drm specs you come to
realize buffer handling is
For the fbdev layer the you have your struct fb_var_screeninfo and also
struct fb_videomode. The struct fb_videomode was developed for the modes
database we have. Struct fb_var_screeninfo is more than just resolution
data which is why we create struct fb_videomode. The really nice thing
is
For the fbdev layer the you have your struct fb_var_screeninfo and also
struct fb_videomode. The struct fb_videomode was developed for the modes
database we have. Struct fb_var_screeninfo is more than just resolution
data which is why we create struct fb_videomode. The really nice thing
Here is the second version of the patch. It address the issues you brought
up.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5054970..0c8c756 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -581,6 +581,101 @@ int
On Thu, 11 Mar 2010, Michal Suchanek wrote:
On 11 March 2010 16:17, James Simmons jsimm...@infradead.org wrote:
It would be nice to find a way to reclaim the console memory for X,
but I'm not sure that can be done and still provide a good way to
provide oops support.
What do
It would be nice to find a way to reclaim the console memory for X,
but I'm not sure that can be done and still provide a good way to
provide oops support.
What do you think the average user will care about more?
* Seeing kernel oops/panic output about once in a lifetime.
Would anyone have objections if these lists moved to freedesktop.org?
The recent thread with Linus about the drm pull request highlights the
post lag and non-subscriber aspect of the current lists, and that
leaves aside sf.net's horrible mail archive interface and poor
performance.
If
On 21 November 2009 05:27, Dave Airlie airl...@gmail.com wrote:
At the moment the problem with fbset is what to do with it in the
dual head case. Currently we create an fb console that is lowest
common size of the two heads and set native modes on both,
Does that mean that fbset is
At the moment the problem with fbset is what to do with it in the
dual head case. Currently we create an fb console that is lowest
common size of the two heads and set native modes on both,
Does that mean that fbset is supposed to work (set resolution) on drmfb?
No we've never hooked
My main problem with calling the drm underneath the fbdev is it
seems like a layering violation. Then again some of code in the kernel
is also contributing to this violation. I'd really like to make fbdev more
like an in-kernel version of what X driver have to do, and leave all the
initial
I don't think so. There is another driver which does this -
vesa/uvesa. For these it is not possible to change the resolution from
fbdev, it just provides some framebuffer on top of which fb
applications or fbcons run.
Only because that is the only way to do it. The other options was to have
Yuck. See my other post about what fbdev really means in its historical
context. The struct fb_info really maps better to drm_crtc than to
drm_framebuffer. In fact take the case of the matrox fbdev driver. It
creates two framebuffer devices even tho it used one static framebuffer.
What
There are other drivers that support multihead already (matroxfb, any
other?) and have their own driver-specific inteface.
Each crtc is treated as a seperate fbdev device. I don't recall any
special ioctls. Maybe for mirroring which was never standardized.
matroxfb does have a
I don't think the CRTC=fb_info makes much sense if the main use
case is fbcon. fbcon will use a single fb device and so you can't see
the console on multiple heads anyway which makes the whole thing
somewhat pointless. And if you're trying to do something more complex
you will be a lot
Yuck. See my other post about what fbdev really means in its historical
context. The struct fb_info really maps better to drm_crtc than to
drm_framebuffer. In fact take the case of the matrox fbdev driver. It
creates two framebuffer devices even tho it used one static framebuffer.
What
Okay all the discussion about multiple display brings me to why I'm doing
this. I'm attempting to revive the linux console project. I'm in a
position to again work on this project. About 4 years ago the eproject
managed to get multi-seat working. My goal is to get there again. My first
goal
i've tried to run this old X server with new (2.6.32) kernel
here is log from startup :
http://83.18.229.190/Xorg/Xorg.0.log.old_X_new_kernel
what is stunning - DRI works , and i get stunning 360fps
with gears turning _smoothly_ in glxgears.
downsides - switching to VT doesn't work.
Second, in the KMS case, we'd be able to skip the kernel VT switch,
because
the KMS driver uses its own framebuffer anyway.
So, is there any reasonable way to check that from the outside of the
graphics
driver? It should be general enough to cover the cases when there are
On Thu, 2010-01-21 at 09:09 +0800, Zhenyu Wang wrote:
On 2010.01.20 13:14:23 +, James Simmons wrote:
It's just adding the backlight api to the intel driver. In fact it gives
the user the ablity to control the brightness of the backlight which I
see
is lacking
On 2010.01.19 16:17:56 +, James Simmons wrote:
Sorry I meant the backlight power management state seperate from the
encoder state.
drm_fb_helper_off() will find fb's crtc and attached encoders, then
call encoder_funcs-dpms() and turn off crtc, so for your DRM_MODE_DPMS_ON
uses DRM_MODE_DPMS_ON for FB_BLANK_NORMAL, but DRM_MODE_DPMS_ON
is actually for turning output on instead of blank.
This makes fb blank broken on my T61, it put LVDS on but leave
pipe disabled which made screen totally white or caused some
'burning' effect.
Cc: James
When Fedora 12 loads i915 during initramfs probing on my system, the
driver automatically installs a tiny 160x64 font. How can I prevent it
from doing this, or tell it to use a larger 80x25 font instead?
Is this documented anywhere?
Not really. Here is how you enable larger fonts.
commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e
Author: James Simmons jsimm...@infradead.org
Date: Thu Oct 29 20:39:07 2009 +
drm/kms: properly handle fbdev blanking
uses DRM_MODE_DPMS_ON for FB_BLANK_NORMAL, but DRM_MODE_DPMS_ON
is actually for turning output on instead
On 01/07/2010 12:42 AM, Johan Hovold wrote:
Yeap. The fix uncovered a bug in your driver. I haven't heard of
problems with the other drm drivers.
The backlight is handled via the DRI driver I assume. At least
i9xx_crtc_dpms is called on powerdown.
Can you post
Yeap. I can have patch ready for you this weekend. I lack the hardware to
test it tho. Never been able to find a intel pci card that is not built
into the motherboard.
They don't exist, other than the old i740s.
I noticed the same is true for SiS cards.
On 01/07/2010 12:42 AM, Johan Hovold wrote:
Yeap. The fix uncovered a bug in your driver. I haven't heard of
problems with the other drm drivers.
The backlight is handled via the DRI driver I assume. At least
i9xx_crtc_dpms is called on powerdown.
Can you post
On 01/07/2010 12:42 AM, Johan Hovold wrote:
Yeap. The fix uncovered a bug in your driver. I haven't heard of problems
with the other drm drivers.
The backlight is handled via the DRI driver I assume. At least
i9xx_crtc_dpms is called on powerdown.
Can you post your dmesg and
Commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e (drm/kms: properly
handle fbdev blanking) breaks console blanking on my laptop (GM45
chipset). Instead of blanking the screen, it is dimmed and then the
backlight starts glowing in the lower edges of the screen. The glowing
then slowly spreads
Commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e (drm/kms: properly
handle fbdev blanking) breaks console blanking on my laptop (GM45
chipset). Instead of blanking the screen, it is dimmed and then the
backlight starts glowing in the lower edges of the screen. The glowing
then
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation: ...
patch:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
Those patches will enable fbdev apps to run
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to
change
video mode, because of different var-pixclock evaluation: ...
patch:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
Those patches will
On Fri, 20 Nov 2009, Paulius Zaleckas wrote:
On 11/20/2009 10:01 PM, James Simmons wrote:
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to
change
video mode, because of different var-pixclock evaluation
On Tue, 2009-11-10 at 14:30 -0800, Andrew Morton wrote:
On Wed, 4 Nov 2009 20:03:19 +0100
Jerome Glisse jgli...@redhat.com wrote:
Just do nothings crct_set_base i call with no FB.
hmpf. It's obvious that you spent hours carefully describing this
patch for us.
Sorry,
Without an allocated colormap, FBIOGETCMAP fails. This would make
programs restore an all-black colormap (links -g) or fail to work
altogether (mplayer -vo fbdev2).
Signed-off-by: Clemens Ladisch clem...@ladisch.de
---
v2: implemented suggestions by James Simmons
drivers/gpu/drm
Without an allocated colormap, FBIOGETCMAP fails. This would make
programs restore an all-black colormap (links -g) or fail to work
altogether (mplayer -vo fbdev2).
Signed-off-by: Clemens Ladisch clem...@ladisch.de
---
Untested.
--- linux-2.6/drivers/gpu/drm/i915/intel_fb.c
+++
I examines several fbdev drivers and foudn the blanking code in
drm_fb_helper to be wrong. This patch fixes the fbdev blanking to behave
like other fbdev drivers.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index dc8e374..68061fc 100644
---
Indeed this seems to be a typo, the important thing is to get someone
like Dave Airlie to pick it up.
Yup I've picked this up in my queue.
Do you have a time window where only bug fixes go in versus improvements?
If that is the case what are the time schedules.
I believe this is a typo.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9c92461..dc8e374 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -707,7 +707,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
Hi!
This patch takes a little explaining. After the cleaned up of the fbdev
api a few years back I realized the fbdev api had many short comings. One
of them was the mapping of 1 to 1 for the framebuffer to display. So I
started to move that way gradually. What ended up was a new struct
What is the git path for the mdoeset repo. I have some patches I like to
submit.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year.
Hi Jon,
What about isolating interrupt-handling code into a small driver ?
Something simple to respond to interrupts and call all handlers with a
certain mask.
This would be useful not only for drm and fbdev but also for km
(v4l capture module) and stereo-glasses code.
Ultimatly this is the goal. That is what the struct xxx_par is for in
struct fb_info. It is the core driver private data that can be shared by
everyone. Ben would you mind if I reworked your code to have this core.
It will take me some time but I can have it working. I need to do some
As far as I know none of the significant contributors on either fbdev
or DRM are being paid to work on the project.
So I have noticed. There is much to do but no real man power. We are
talking about this merging but at our rate it will take 5 years to happen.
We don't have the man power to
Do you see any other solution to this then?
You could build this inside of the DRM framework which already
supports DMA and memory management. DRM doesn't really know anything
about 3D, it just knows how to send commands to the graphics hardware.
It's the mesa layer in user space that
1. Lots of work that would take lots of time. To my knowledge all fbdev
developers work in there spare free time. No one does this for a
living.
So do most of the drm developers, I know I do and Jon Smirl does, and
Eric Anholt does and I think us three have been the largest
That app must be pretty big if it runs on non intel platforms. You nedd to
translate the x86 BIOS code to native assembly before you run it.
On Wed, 12 May 2004, Richard Smith wrote:
Jon Smirl wrote:
licenses). I've already built a very messy prototype by moving the existing
fbdev code
That app must be pretty big if it runs on non intel platforms. You nedd to
translate the x86 BIOS code to native assembly before you run it.
Or interprete it.
Only if we could use Java for the video BIOS.
Java? em86 (written by Gabriel Paubert) has been working fine on my PPC
That app must be pretty big if it runs on non intel platforms. You nedd to
translate the x86 BIOS code to native assembly before you run it.
Or interprete it.
Only if we could use Java for the video BIOS.
---
This SF.Net email is
What this is saying is that very early in the boot process the graphics driver
will be initialized. At this point it will generate a hotplug event. This event
will be handled by an app and lib that live in initramfs. This is not saying
that mode-setting will be delayed until normal user
I don't think that's a good idea: dri-devel is limited to the platforms that
have a working DRI implementation, while linux-fbdev-devel is also frequented
by people from platforms without DRI.
And there we see a communication problem again: the DRI was started without
talking to fbdev
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. (Basic to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't
never win this fight. There is MONEY involved here. This is
But we are rendering to draw fonts, clearing a area of the screen,copyarea.
If we are to have a universal solution it needs to OpenGL. Either that or
mode switching stays in the kernel.
Drawing fonts have _NOTING_ to do with mode switching ! Don't tell me
that you can't make the
single kernel driver should muck with the hardware directly. However,
I'd like to point out again that it doesn't follow that the DRM and the
framebuffer device must merge to a single entity (which 'has to be' the
DRM if you ask some people, the framebuffer device if you ask
others...).
On Mon, May 10, 2004 at 10:39:50PM +, Nicolas Souchu wrote:
Do apps manage their swap? No. I think the OS should be responsible for
placing the data (vertices, textures, commands) at the right/best place
for the HW 3D engine and the client should only fill virtual memory.
Also, these is no rule saying a device driver can't have several tables of _init
register values that can be used to set the mode on a primary monitor at boot. I
would just like to see all of the code that does DDC decoding and modeline
computations moved to user space. When you add up that
You are mixing things. Mode setting has nothing to do with rendering. OpenGL
is a rendering client. It produces commands sent to the low level kernel
driver and provides a 3D API, but it's not the only one. In this regard,
fbcon is a client too and XFree 2D accel is another one.
But we are
It's not just bloat, the network code is used millions of times per second.
Mode setting happens occaisonally.
Using that logic then Sound cards shouldn't be in the kernel at all. I
never use my sound card continuely. I use it as a module. Would it be
acceptable if the mode setting was
Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.
IIRC, the main reasons were:
- GGI wanted to do too much at once and was too intruisive (conclusion:
always advance in small steps, not big leaps):
o
But who cares? Do you really intend to keep a common BSD and Linux API/code base?
Offering both solutions under BSD and GPL would be good for suggesting correct
license usage in the embedded world. GPL is too often bypassed.
What about a dual license.
The big reason for merging is memory
Since they have to co-operate some way on the resources _anyway_, they'll
just need to work it out amongst themselves.
One common case is to have a arbitration driver that tends to do the
actual low-level accesses and is one level of abstraction over the
hardware (papers over trivial
I see your point about fbdev not beeing the proper interface here.
But then, what would be the relationchip between that low level stuff
and fbdev ?
My suggestion, as a starting point, is to really think very rudimentary at
first. A truly _minimal_ thing. Minimal partly because that
nice work!
i know you are working with the dri fb drivers, is
any progress and what is the current state?
I am working on embedded Mesa, which is another name
for standalone OpenGL. Embedded Mesa is based on the
3D DRI code but it handles 2D very differently.
Xfree/DRI scans the
73 matches
Mail list logo
