On Tue, Nov 5, 2024 at 10:16 AM Yuqian Yang wrote:
> > 1. the ioctl ID encoding space is fully used already -- all the bits
> > in an ioctl ID are meaningful, so there'd be nowhere to pack the new
> > info;
>
> What does this mean? So we can't create new ioctl op and args for drm
> with the same v
Hello,
Note that you are not stuck with ioctl's parsing. You can use
_HURD_HANDLE_IOCTL and _HURD_HANDLE_IOCTLS to define client-side
interpretation of of the ioctl parameter, to be able to cast that into
an RPC just like you prefer instead of the IOT things.
Samuel
It sounds like we need to implement a wrapping-paper thin layer in
libdrm
that unpacks drmIoctl() and fans out all the combinations of proper
RPCs;
it will be ugly but doable. (I was hoping we could just pass in a
casted struct as that is what an ioctl is for). This is more work,
but probably s
Hi,
On 11/5/24 6:16 PM, Yuqian Yang wrote:
> In conclusion, there is no way to do things like using a pointer to pass
> data pointed by it in Mach. I can understand this is rooted in Mach
> design. This does create problems of mimicking API in Linux to reuse a
> lot of high-level things. At least
1. the ioctl ID encoding space is fully used already -- all the bits
in an ioctl ID are meaningful, so there'd be nowhere to pack the new
info;
What does this mean? So we can't create new ioctl op and args for drm
with the same value in Linux?
2. where would the received pointer point? -- in
On Mon, Nov 4, 2024 at 10:44 AM Damien Zammit wrote:
> I am currently attempting to implement a drm server to provide
> a way to use libdrm with multiboot framebuffer exposed by new device(mbinfo).
>
> I am running into a problem that I am unable to implement a compatible
> ioctl api because of the
Hello Damien
On Mon, Nov 4, 2024 at 2:44 AM Damien Zammit via Bug reports for the GNU
Hurd wrote:
> Hi,
>
> I am currently attempting to implement a drm server to provide
> a way to use libdrm with multiboot framebuffer exposed by new
> device(mbinfo).
>
> I am running into a problem that I am u
Hi,
I am currently attempting to implement a drm server to provide
a way to use libdrm with multiboot framebuffer exposed by new device(mbinfo).
I am running into a problem that I am unable to implement a compatible
ioctl api because of the layout of the structures.
I would prefer to reuse the s