Purpose of parameter in sysfs binary read
Rick L. Vinyard, Jr.
signature:
ssize_t (*read)(struct kobject *kobj, struct bin_attribute *attr,
char *buf, loff_t offset, size_t size);
I've figured out the purpose of all the parameters except the loff_t
parameter.
Obviously it's an offset of some sort, but what is the meaning of the offset?
If I have binary data in a char* named bindata of size bsize, should it be
copied into buf+offset in something like:
memcpy(buf+offset, bindata, bsize);
Or, is it an offset from both buf and bindata in something like:
memcpy(buf+offset, bindata+offset, bsize-offset);
Thanks,
Rick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
> The read function pointer of the sysfs bin_attribute structure has this
> signature:
>
> ssize_t (*read)(struct kobject *kobj, struct bin_attribute *attr,
> char *buf, loff_t offset, size_t size);
>
> I've figured out the purpose of all the parameters except the loff_t
> parameter.
>
> Obviously it's an offset of some sort, but what is the meaning of the offset?
The same as any read() call, it comes from the vfs.
> If I have binary data in a char* named bindata of size bsize, should it be
> copied into buf+offset in something like:
> memcpy(buf+offset, bindata, bsize);
>
> Or, is it an offset from both buf and bindata in something like:
> memcpy(buf+offset, bindata+offset, bsize-offset);
What are you using the binary sysfs attribute for? It should ONLY be
used as a pass-through to and from hardware, with no interpretation by
the kernel at all.
See the existing users of this interface in the kernel for examples of
how to use the offset parameter.
thanks,
greg k-h
Alan Stern
> The read function pointer of the sysfs bin_attribute structure has this
> signature:
>
> ssize_t (*read)(struct kobject *kobj, struct bin_attribute *attr,
> char *buf, loff_t offset, size_t size);
>
> I've figured out the purpose of all the parameters except the loff_t
> parameter.
>
> Obviously it's an offset of some sort, but what is the meaning of the offset?
It's the same offset argument that's found in all read or write
methods for all types of files. It refers to the offset from the start
of the file.
> If I have binary data in a char* named bindata of size bsize, should it be
> copied into buf+offset in something like:
> memcpy(buf+offset, bindata, bsize);
>
> Or, is it an offset from both buf and bindata in something like:
> memcpy(buf+offset, bindata+offset, bsize-offset);
Neither one. If the kernel wanted to add an offset to buf, it would
have done so before calling the function. The code should be more like
this:
memcpy(buf, bindata + offset, min(size, bsize - offset));
Alan Stern
Rick L. Vinyard, Jr.
> On Tue, Aug 18, 2009 at 08:55:29AM -0600, Rick L. Vinyard, Jr. wrote:
> What are you using the binary sysfs attribute for? It should ONLY be
> used as a pass-through to and from hardware, with no interpretation by
> the kernel at all.
It's for the Logitech G13's game panel image (a simple binary bitmap of
the pixels).
It doesn't do any interpretation... just a few checks on the magic number
and size.
Rick L. Vinyard, Jr.
> On Tue, 18 Aug 2009, Rick L. Vinyard, Jr. wrote:
>
> Neither one. If the kernel wanted to add an offset to buf, it would
> have done so before calling the function. The code should be more like
> this:
>
> memcpy(buf, bindata + offset, min(size, bsize - offset));
>
Ahhh, offset into the binary data.
Thanks.
Greg KH
> Greg KH wrote:
> > On Tue, Aug 18, 2009 at 08:55:29AM -0600, Rick L. Vinyard, Jr. wrote:
> > What are you using the binary sysfs attribute for? It should ONLY be
> > used as a pass-through to and from hardware, with no interpretation by
> > the kernel at all.
>
> It's for the Logitech G13's game panel image (a simple binary bitmap of
> the pixels).
>
> It doesn't do any interpretation... just a few checks on the magic number
> and size.
Cool. Have a pointer to the driver yet?
thanks,
greg k-h
Rick L. Vinyard, Jr.
> On Tue, Aug 18, 2009 at 09:41:56AM -0600, Rick L. Vinyard, Jr. wrote:
>> Greg KH wrote:
>> > On Tue, Aug 18, 2009 at 08:55:29AM -0600, Rick L. Vinyard, Jr. wrote:
>> > What are you using the binary sysfs attribute for? It should ONLY be
>> > used as a pass-through to and from hardware, with no interpretation by
>> > the kernel at all.
>>
>> It's for the Logitech G13's game panel image (a simple binary bitmap of
>> the pixels).
>>
>> It doesn't do any interpretation... just a few checks on the magic
>> number
>> and size.
>
> Cool. Have a pointer to the driver yet?
>
Not quite ready yet. Still trying to figure out how to handle the input
buttons in the hid framework.
There is another driver out there, but they went outside the hid driver
and established an interrupt urb and I'm still familiarizing myself with
how the hid driver handles interrupts so I can get the keypresses.
Everything else (backlight control and loading game panel images) seems to
be working though.
Alan Cox
"Rick L. Vinyard, Jr." <rvin...@cs.nmsu.edu> wrote:
> Greg KH wrote:
> > On Tue, Aug 18, 2009 at 08:55:29AM -0600, Rick L. Vinyard, Jr. wrote:
> > What are you using the binary sysfs attribute for? It should ONLY be
> > used as a pass-through to and from hardware, with no interpretation by
> > the kernel at all.
>
> It's for the Logitech G13's game panel image (a simple binary bitmap of
> the pixels).
>
> It doesn't do any interpretation... just a few checks on the magic number
> and size.
If its a bitmap image why not register the device as a framebuffer ?
Rick L. Vinyard, Jr.
> On Tue, 18 Aug 2009 09:41:56 -0600
> "Rick L. Vinyard, Jr." <rvin...@cs.nmsu.edu> wrote:
>
>> Greg KH wrote:
>> > On Tue, Aug 18, 2009 at 08:55:29AM -0600, Rick L. Vinyard, Jr. wrote:
>> > What are you using the binary sysfs attribute for? It should ONLY be
>> > used as a pass-through to and from hardware, with no interpretation by
>> > the kernel at all.
>>
>> It's for the Logitech G13's game panel image (a simple binary bitmap of
>> the pixels).
>>
>> It doesn't do any interpretation... just a few checks on the magic
>> number
>> and size.
>
> If its a bitmap image why not register the device as a framebuffer ?
>
Would that preclude it also being registered as a HID? The primary purpose
of the device is to function as a keypad input.
But, in addition to sending keystroke output you can send a usb control
message to change the backlight color and an interrupt message to load a
bitmap as an image.
The bitmap itself is simple, but requires a specific format. Byte 0 must
be 0x03 followed by 31 bytes of null. The low bit of byte 32 is x,y (0,0)
second high bit is (0,1)... with low bit of byte 33 being (1,0)...
Alan Cox
> message to change the backlight color and an interrupt message to load a
> bitmap as an image.
Ok that actually fits the LCD interface model a bit better, but the LCD
class right now is a hack inside of a single driver so eventually needs
fixing
> The bitmap itself is simple, but requires a specific format. Byte 0 must
> be 0x03 followed by 31 bytes of null. The low bit of byte 32 is x,y (0,0)
> second high bit is (0,1)... with low bit of byte 33 being (1,0)...
How big is it and can it be used for general purpose graphics - I know
the G19 is something like 320x240 but the G13 ?
Greg KH
> Alan Cox wrote:
> > On Tue, 18 Aug 2009 09:41:56 -0600
> > "Rick L. Vinyard, Jr." <rvin...@cs.nmsu.edu> wrote:
> >
> >> Greg KH wrote:
> >> > On Tue, Aug 18, 2009 at 08:55:29AM -0600, Rick L. Vinyard, Jr. wrote:
> >> > What are you using the binary sysfs attribute for? It should ONLY be
> >> > used as a pass-through to and from hardware, with no interpretation by
> >> > the kernel at all.
> >>
> >> It's for the Logitech G13's game panel image (a simple binary bitmap of
> >> the pixels).
> >>
> >> It doesn't do any interpretation... just a few checks on the magic
> >> number
> >> and size.
> >
> > If its a bitmap image why not register the device as a framebuffer ?
> >
>
> Would that preclude it also being registered as a HID? The primary purpose
> of the device is to function as a keypad input.
Is the framebuffer a different USB interface? Or are they all
controlled through the same one?
thanks,
greg k-h
Rick L. Vinyard, Jr.
>> But, in addition to sending keystroke output you can send a usb control
>> message to change the backlight color and an interrupt message to load a
>> bitmap as an image.
>
> Ok that actually fits the LCD interface model a bit better, but the LCD
> class right now is a hack inside of a single driver so eventually needs
> fixing
>
>> The bitmap itself is simple, but requires a specific format. Byte 0 must
>> be 0x03 followed by 31 bytes of null. The low bit of byte 32 is x,y
>> (0,0)
>> second high bit is (0,1)... with low bit of byte 33 being (1,0)...
>
> How big is it and can it be used for general purpose graphics - I know
> the G19 is something like 320x240 but the G13 ?
>
160x43 --- The same as the G15 and MX5000 keyboards. In fact, it takes the
same bitmap pattern as the keyboards.
160x43 is small, but some graphics are definitely possible, console/text
is certainly possible.
Rick L. Vinyard, Jr.
Same USB interface. That's why I was thinking it might not work out. In
fact, it uses the same interrupt pipe as the HID reports.
Alan Cox
> same bitmap pattern as the keyboards.
>
> 160x43 is small, but some graphics are definitely possible, console/text
> is certainly possible.
Ultimately it should probably also create a console device of itself, but
its not something trivial to do and I really wouldn't bother about it
until it works in current form if ever...
Mind you a keyboard that has the display built in would be really useful
for poking around server boxes on racks.
Alan
Pavel Machek
> > If its a bitmap image why not register the device as a framebuffer ?
> >
>
> Would that preclude it also being registered as a HID? The primary purpose
> of the device is to function as a keypad input.
>
> But, in addition to sending keystroke output you can send a usb control
> message to change the backlight color and an interrupt message to load a
> bitmap as an image.
>
> The bitmap itself is simple, but requires a specific format. Byte 0 must
> be 0x03 followed by 31 bytes of null. The low bit of byte 32 is x,y (0,0)
> second high bit is (0,1)... with low bit of byte 33 being (1,0)...
Sounds very much like auxdisplay things we already have in tree...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Rick L. Vinyard, Jr.
>> 160x43 --- The same as the G15 and MX5000 keyboards. In fact, it takes
>> the
>> same bitmap pattern as the keyboards.
>>
>> 160x43 is small, but some graphics are definitely possible, console/text
>> is certainly possible.
>
> Ultimately it should probably also create a console device of itself, but
> its not something trivial to do and I really wouldn't bother about it
> until it works in current form if ever...
>
> Mind you a keyboard that has the display built in would be really useful
> for poking around server boxes on racks.
>
I have the display as a framebuffer device now (based on fbdefio with the
hid device as the parent).
Do I really need a separate console device or can I just use fbcon?
Alan Cox
> hid device as the parent).
>
> Do I really need a separate console device or can I just use fbcon?
fbcon should do what you want.
ALan
Rick L. Vinyard, Jr.
>> I have the display as a framebuffer device now (based on fbdefio with
>> the
>> hid device as the parent).
>>
>> Do I really need a separate console device or can I just use fbcon?
>
> fbcon should do what you want.
>
I've been playing with fbcon, but can't get a fbcon console started.
I wrote a little app that uses the framebuffer ioctls to change fbcon's
map. Specifically, the G13 shows up as fb1, and the app basically does
this:
int fd = open("/dev/fb1", O_RDWR);
struct fb_con2fbmap con2fb;
int ret;
if ( fd < 0 ) { printf("Error opening %s\n", DEVICE); return -1; }
con2fb.console = 5;
ioctl(fd, FBIOGET_CON2FBMAP, &con2fb);
printf("Console: %d Framebuffer: %d\n", con2fb.console,
con2fb.framebuffer);
con2fb.framebuffer = 1;
ret = ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb);
printf("Succeeded: %d\n", ret);
ioctl(fd, FBIOGET_CON2FBMAP, &con2fb);
printf("Console: %d Framebuffer: %d\n", con2fb.console,
con2fb.framebuffer);
This succeeds and I get:
Console: 5 Framebuffer: 0
Succeeded: 0
Console: 5 Framebuffer: 1
But, when I change to console 5 that's when things die. I never hit any of
my fb_ops callbacks.
The driver can be found here:
http://g13.svn.sourceforge.net/viewvc/g13/driver/trunk/hid-g13.h
http://g13.svn.sourceforge.net/viewvc/g13/driver/trunk/hid-g13.c
This doesn't actually do anything but do a printk (in hex) of the
framebuffer memory.
When I modify the framebuffer through a mmap I don't have any problems,
but when I switch to the console the kernel hangs.
I'm currently recompiling the kernel with FBCONDEBUG defined and I'll test
from there.
Any other suggestions on how to approach this?
Thanks,
---
Rick