On Fri, 3 Jul 2009 09:02:15 +0200 (CEST) Mark Kettenis <[email protected]> wrote:
> > Date: Wed, 1 Jul 2009 13:15:03 -0700 > > From: Jesse Barnes <[email protected]> > > > > For Moblin, we'd like to be able to run X as a non-root user, so > > with that in mind I spent a few hours looking at what it would take > > to get X running w/o root perms on the latest bits using the > > xf86-video-intel driver (note Dave did this about a year ago, but I > > guess the bits didn't make it upstream). Turns out now that all the > > pieces are in place it was really easy. X needed root on Linux for > > a few things: 1) I/O probing > > 2) tty/VT probing & ownership > > 3) some DRM ioctls > > 4) some PCI related probing > > 5) input perms > > > > However, with a KMS enabled driver that doesn't do I/O access, (1) > > and (4) aren't really necessary anymore. For (3), just a couple of > > ioctls need to have their "root only" status stripped (safely I > > think). And for (2) and (5), distro pam scripts can take care of > > things (as long as X is started on a tty that has had its > > ownership/perms modified appropriately). > > > > So this small patch is all that's necessary on the X side (the DRM > > patch is trivial, and half of it has already been posted to > > dri-devel). It's a big hackish, so I'm just requesting comments at > > this point. I'd like to do the -nohwaccess part better, but think > > doing it well will require a driver ABI change (maybe just a new > > flags field that indicates whether the driver needs I/O ports > > enabled, or we can push the xf86EnableIO call into drivers as > > needed). > > Jesse, thinking about I/O ports as an all-on/all-off thing is too > PC-centric I'm afraid. Or actually, the whole concept of I/O "ports" > is. On most other architectures (SPARC, PowerPC, ARM to name a > couple) I/O cycles on the PCI bus are generated by memory mapping just > like what is done for memory cycles. Therefore, I think the drivers > should really exlicitly map the I/O space they need using > pci_device_map_range(). Perhaps a seperate call is needed to map > legacy VGA I/O space; this should probably tie in with the (mythical?) > VGA arbiter that has been talked about. Oh I know it. :) Drivers really should be more specific about their needs. If we can wrap the actual legacy I/O port requirement into the VGA arbiter, I think the rest will be taken care of by PCI device mapping and perms (leaving aside funky busses). -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
