Hi,
On Tue, Sep 04, 2007 at 10:52:41AM -0700, Jesse Barnes wrote:
On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote:
As for EDID, I totally agree that this can be done in user space
just fine. What I'm saying is that no central daemon is required for
that. Handling this data
On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote:
Hi,
On Fri, Aug 24, 2007 at 08:31:10AM -0700, Jesse Barnes wrote:
On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED]
wrote:
I am *not* opposed to a scheme where userspace has to provide
information how to set up a
Hi,
On Fri, Aug 24, 2007 at 08:31:10AM -0700, Jesse Barnes wrote:
On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote:
I am *not* opposed to a scheme where userspace has to provide
information how to set up a desired mode. (Although I'm not conviced
it's really necessary --
Hi,
On Fri, Aug 24, 2007 at 06:08:57AM +0300, Daniel Stone wrote:
On Fri, Aug 24, 2007 at 03:50:04AM +0200, [EMAIL PROTECTED]
wrote:
Graphics chips are complicated, but the bulk of the complexity is
not in modesetting. Do you really think that modesetting (and other
graphics hardware
On Aug 23, 07 12:00:39 +0300, Daniel Stone wrote:
If you have ioctl number 32, your next free one is 43, and you want to
change the semantics of UPDATE_WINDOW, then you rename 32 to
UPDATE_WINDOW_OLD, create UPDATE_WINDOW as 43 with the new structure,
and handle both cases.
I
On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote:
I am *not* opposed to a scheme where userspace has to provide
information how to set up a desired mode. (Although I'm not conviced
it's really necessary -- both Keith Packard and Dave Airlie argued that
mode setting is simple
On Thursday, August 23, 2007 8:38:46 pm Tiago Vignatti wrote:
I hope you guys are not forgetting who wants to start two (or more)
instances of the Xorg server (for multiseat purposes or what ever).
Oh definitely not. This work should make muliseat much easier.
In this case, the daemon - in
At a minimum, there must be a program to determine which outputs have
monitors
attached, and what modes are available on those monitors. It's possible this
could be hardcoded in simple or embedded cases, but for a dynamic system it
should probably be done in userspace, since EDID
On Wed, 2007-08-22 at 20:09 +0200, Matthias Hopf wrote:
On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote:
Without a version field, this is made impossible, something that must be
avoided at all costs.
Except that your ioctl then becomes variably-sized unless you add loads
of
On Wed, Aug 22, 2007 at 08:09:18PM +0200, Matthias Hopf wrote:
On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote:
But that exactly makes version control difficult (lots of cases,
especially if the exact requirements aren't clear from day one).
I honestly don't understand the problem.
Hi,
On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote:
On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
I fail to understand why you want to put the manager in a daemon,
instead of just letting the kernel do the management, like it does
for all other hardware. Why is
Hi,
On Sun, Aug 12, 2007 at 09:36:32PM -0700, Jesse Barnes wrote:
On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote:
I fail to understand why you want to put the manager in a daemon,
instead of just letting the kernel do the management, like it does
for all other hardware. Why
On Fri, Aug 24, 2007 at 03:50:04AM +0200, [EMAIL PROTECTED] wrote:
Graphics chips are complicated, but the bulk of the complexity is not in
modesetting. Do you really think that modesetting (and other graphics
hardware management) is more complex than say a wireless network driver?
The API
Hi,
[EMAIL PROTECTED] escreveu:
On Sun, Aug 12, 2007 at 09:36:32PM -0700, Jesse Barnes wrote:
On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote:
I fail to understand why you want to put the manager in a daemon,
instead of just letting the kernel do the management, like it does
On Aug 20, 07 19:51:31 +0300, Daniel Stone wrote:
On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote:
On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
There should be master (possibly one for each card) which
On Aug 20, 07 15:45:00 -0700, Keith Packard wrote:
On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote:
Because we won't get an ix86 emulator in kernel space, Linus and others
have been pretty clear about that. Graphics hardware sometimes needs
BIOS calls, on non-i386 hardware that has
On Wed, Aug 22, 2007 at 03:42:49PM +0200, Matthias Hopf wrote:
On Aug 20, 07 19:51:31 +0300, Daniel Stone wrote:
On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote:
On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
Please be sure that if you design this using ioctls the
On Wed, Aug 22, 2007 at 03:47:31PM +0200, Matthias Hopf wrote:
No. But you already limit yourself to the primary card, a new design
shouldn't be limited that way. And an astonishingly big number of people
have to rely on vesa fb, because driver development for their hardware
sucks big time (no
On Wednesday, August 22, 2007 6:47:31 am Matthias Hopf wrote:
On Aug 20, 07 15:45:00 -0700, Keith Packard wrote:
On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote:
Because we won't get an ix86 emulator in kernel space, Linus and others
have been pretty clear about that. Graphics
On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote:
But that exactly makes version control difficult (lots of cases,
especially if the exact requirements aren't clear from day one).
I honestly don't understand the problem. Your ioctl number is _that_
request. It's not referring to a vague
On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
There should be master (possibly one for each card) which be the only
one being able to do this call:
DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
Please be sure that if
On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote:
On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
There should be master (possibly one for each card) which be the only
one being able to do this call:
On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote:
Because we won't get an ix86 emulator in kernel space, Linus and others
have been pretty clear about that. Graphics hardware sometimes needs
BIOS calls, on non-i386 hardware that has to be done by an emulator.
Post-boot, for the primary
Hi,
On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
There should be master (possibly one for each card) which be the only
one being able to do this call:
DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
[...]
master (big boss)
- X server (got its framebuffer)
- X
On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote:
Hi,
On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
There should be master (possibly one for each card) which be the only
one being able to do this call:
DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
[...]
Jesse Barnes wrote:
I finally found some time to create a new wiki page for all the
modesetting/configuration related DRM enhancements we've been talking about:
http://dri.freedesktop.org/wiki/DrmModesetting
Please take a look and let me know what you think. I still have to go
through
On Thu, 2007-08-02 at 17:44 +0200, Jerome Glisse wrote:
Btw i think that some GPU can wait on vblank using cmd ie you
don't need to ask the card to emit irq you just insert a cmd in
stream which stall further cmd execution until vblank happen,
this might be good for power consumption.
It's
Michel Dänzer wrote:
On Thu, 2007-08-02 at 17:44 +0200, Jerome Glisse wrote:
Btw i think that some GPU can wait on vblank using cmd ie you
don't need to ask the card to emit irq you just insert a cmd in
stream which stall further cmd execution until vblank happen,
this might be good for power
Jesse Barnes wrote:
I finally found some time to create a new wiki page for all the
modesetting/configuration related DRM enhancements we've been talking about:
http://dri.freedesktop.org/wiki/DrmModesetting
Please take a look and let me know what you think. I still have to go
through
On 02/08/07, Jerome Glisse [EMAIL PROTECTED] wrote:
Jesse Barnes wrote:
I finally found some time to create a new wiki page for all the
modesetting/configuration related DRM enhancements we've been talking about:
http://dri.freedesktop.org/wiki/DrmModesetting
Please take a look and let
Well ain't I'm rude not signing off :)
Cheers Jakob Wlallbraker Bornecrekrantz.
I just about can't do anything right to day :)
Cheers Jakob.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log
I don't agree with everything but the general idea is a good one.
There should be master (possibly one for each card) which be the only
one being able to do this call:
DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
(which i assume is set the mode, associat crtc-output and set framebuffer)
Jakob Bornecrantz wrote:
There should be master (possibly one for each card) which be the only
one being able to do this call:
DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
(which i assume is set the mode, associat crtc-output and set framebuffer)
Other call can be made by any others client:
33 matches
Mail list logo
