linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: James Simmons <jsimmons@infradead.org>
Cc: Linux console project <linuxconsole-dev@lists.sourceforge.net>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	DRI development list <dri-devel@lists.sourceforge.net>
Subject: Re: My goal
Date: Thu, 11 Mar 2010 04:47:59 +0000	[thread overview]
Message-ID: <21d7e9971003102047i1531f719i45f7ff1ef308f185@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1003110341550.21470@casper.infradead.org>

On Thu, Mar 11, 2010 at 1:51 PM, James Simmons <jsimmons@infradead.org> wrote:
>
> 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 is to get my netbook to act has a multiseat system for two. With a plugged
> in external montior and a USB keyboard run two concurrent X sessions both
> running OpenGL applications at the same time. I set out to do this 10
> years ago and I want to finally accomplish this.

Hi James,

I had a plan (with a picture) but we lost the picture in a disk crash.

But it basically sounded like this.

Currently we have two device nodes per drm device, a control node
and a legacy card node. The control node is there in theory to support
multi-seat.

The plan was some sort of userspace multi-seat manager (in gdm or
otherwise), would use the control node to divide up the modesetting
resources and create a number of seat nodes. These seat nodes
would operate like the current legacy node except they would only
show the user the modesetting resources assigned to them. The
control node could also be used to create a node with no mode
resources for GPGPU work.

You can see the start of this in the drm, look for mode_group.

Once the kernel was generating the seat nodes, it would be a
matter of giving that path to the X server KMS driver and it would
open that instead of the legacy device node, and same for the
second X server.

This would require of course starting X servers with -sharevts
and -novtswitch most likely.

Dave.
,

  reply	other threads:[~2010-03-11  4:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-11  3:51 My goal James Simmons
2010-03-11  4:47 ` Dave Airlie [this message]
2010-03-11  6:46 ` aivils
2010-03-11 14:57   ` Bernie Thompson
2010-03-18  0:05 ` Dave Airlie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21d7e9971003102047i1531f719i45f7ff1ef308f185@mail.gmail.com \
    --to=airlied@gmail.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linuxconsole-dev@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).