Port-sparc64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Xorg on Blade 150



The "INSECURE" workaround works well; of course, a better solution
should be in place.


Jerome


--

THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments
are proprietary and confidential information intended only for the use
of the recipient(s) named above. If you are not the intended
recipient, you may not print, distribute, or copy this message or any
attachments. If you have received this communication in error, please
notify the sender by return e-mail and delete this message and any
attachments from your computer.


On Tue, Aug 23, 2016 at 9:27 AM, Michael <macallan%netbsd.org@localhost> wrote:
> Hello,
>
> On Tue, 23 Aug 2016 09:21:23 +0200
> Martin Husemann <martin%duskware.de@localhost> wrote:
>
>> On Tue, Aug 23, 2016 at 02:00:37PM +1000, matthew green wrote:
>> > it kind of sucks that we have to turn INSECURE on just for X,
>> > maybe we can have a GENERIC_GRAPHICS that does?  i won't object
>> > whatever you choose.
>>
>> I'd prefer anything that gets it working w/o INSECURE again - but then I don't
>> know how far we will get with that if we move forward with DRM/KMS.
>
> We'd need better control on what can/can't be mapped through /dev/pci*.
> We could also go back to going through /dev/tty[E|F|G|H|...] now that
> they are actually being created. That would require a driver attaching
> to each graphics device though. Problem with that - on most graphics
> chips I've seen the DMA stuff we'd want to restrict isn't sufficiently
> separated from, say, the drawing engine registers ( as in, on a
> different page ).
>
> On SBus that's easier - we already go through /dev/fb*, we've got
> kernel drivers for nearly everything, and most supported cards don't
> really do DMA.
>
> have fun
> Michael



Home | Main Index | Thread Index | Old Index