Purpose of parameter in sysfs binary read

Purpose of parameter in sysfs binary read

[Rick L. Vinyard, Jr.]

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?

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

Re: Purpose of parameter in sysfs binary read

[Greg KH]

On Tue, Aug 18, 2009 at 08:55:29AM -0600, Rick L. Vinyard, Jr. wrote:
> 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

Re: Purpose of parameter in sysfs binary read

[Rick L. Vinyard, Jr.]

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.

Re: Purpose of parameter in sysfs binary read

[Greg KH]

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?

thanks,

greg k-h

Re: Purpose of parameter in sysfs binary read

[Rick L. Vinyard, Jr.]

Greg KH wrote:
> 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.

Re: Purpose of parameter in sysfs binary read

[Alan Cox]

On Tue, 18 Aug 2009 09:41:56 -0600
"Rick L. Vinyard, Jr." <rvinyard@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 ?

Re: Purpose of parameter in sysfs binary read

[Rick L. Vinyard, Jr.]

Alan Cox wrote:
> On Tue, 18 Aug 2009 09:41:56 -0600
> "Rick L. Vinyard, Jr." <rvinyard@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)...

Re: Purpose of parameter in sysfs binary read

[Greg KH]

On Wed, Aug 19, 2009 at 11:41:28AM -0600, Rick L. Vinyard, Jr. wrote:
> Alan Cox wrote:
> > On Tue, 18 Aug 2009 09:41:56 -0600
> > "Rick L. Vinyard, Jr." <rvinyard@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

Re: Purpose of parameter in sysfs binary read

[Rick L. Vinyard, Jr.]

Greg KH wrote:
> On Wed, Aug 19, 2009 at 11:41:28AM -0600, Rick L. Vinyard, Jr. wrote:
>> Alan Cox wrote:
>> > On Tue, 18 Aug 2009 09:41:56 -0600
>> > "Rick L. Vinyard, Jr." <rvinyard@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?
>

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.

Re: Purpose of parameter in sysfs binary read

[Alan Cox]

> 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 ?

Re: Purpose of parameter in sysfs binary read

[Rick L. Vinyard, Jr.]

Alan Cox wrote:
>> 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.

Re: Purpose of parameter in sysfs binary read

[Alan Cox]

> 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.

Alan

Re: Purpose of parameter in sysfs binary read

[Rick L. Vinyard, Jr.]

Alan Cox wrote:
>> 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?

Re: Purpose of parameter in sysfs binary read

[Alan Cox]

> 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.

ALan

Re: Dynamically attaching fbcon to a framebuffer

[Rick L. Vinyard, Jr.]

Alan Cox wrote:
>> 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

Re: Purpose of parameter in sysfs binary read

[Pavel Machek]

Hi!

> > 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

Re: Purpose of parameter in sysfs binary read

[Alan Stern]

On Tue, 18 Aug 2009, Rick L. Vinyard, Jr. wrote:

> 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

Re: Purpose of parameter in sysfs binary read

[Rick L. Vinyard, Jr.]

Alan Stern wrote:
> 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.