lkml.org 
[lkml]   [2010]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] Logitech G13 driver (fixed cc list --- ignore others)
    From
    Miguel Ojeda wrote:
    > On Thu, Jan 14, 2010 at 10:48 PM, Rick L. Vinyard, Jr.
    > <rvinyard@cs.nmsu.edu> wrote:
    >> Miguel Ojeda wrote:
    >>> On Tue, Jan 5, 2010 at 1:14 AM, Jaya Kumar <jayakumar.lkml@gmail.com>
    >>> wrote:
    >>>> On Tue, Jan 5, 2010 at 6:48 AM, Pavel Machek <pavel@ucw.cz> wrote:
    >>>>>
    >>>>> Ok, but I guess you should cc auxdisplay people in future.
    >>>>
    >>>> Hi Pavel,
    >>>>
    >>>> I just looked at the drivers/auxdisplay directory and got a bit
    >>>> confused. The reason I got confused is because auxdisplay is actually
    >>>> an fbdev driver but it is outside of the drivers/video directory. It
    >>>> looks like there has only been 1 commit and that was for the Samsung
    >>>> KS0108 controller. It also sort of uses platform support but the way
    >>>> it is abstracted is odd to my thinking. The controller is ks0108, so
    >>>> in my mind that would be the code that would be platform independent,
    >>>> and then that would use a board specific IO driver to push data (eg:
    >>>> parport or gpio or usb). I think in the long term it would probably
    >>>> make sense to write a cleaner approach with a drivers/video/ks0108.c
    >>>> which is cleanly platform independent (and back within fbdev proper)
    >>>> and then a board specific driver in the appropriate location that
    >>>> handles the IO.
    >>>
    >>> I wrote long ago the driver(s) and people that reviewed it thought it
    >>> was better to keep it outside. I think that if someone else is going
    >>> to need ks0108, then I agree: we should write a independent driver.
    >>>
    >>> It should not be hard, it is an easy controller to play with and the
    >>> code is already there. I would try to do it; however, I am not sure if
    >>> I would be the most appropriate person to code such generic driver, as
    >>> I know almost nothing about all drivers/video/* stuff and the ways of
    >>> making it truly generic for future video/ users. Still, I will help
    >>> gladly.
    >>>
    >>
    >> When I started to look at writing the G13 framebuffer the first code I
    >> looked at was the cfag12864b, and started off trying to adapt it.
    >>
    >
    > I hope it was useful, at least at first. : )
    >
    >> However, as I was digging through the video/* directory looking for
    >> something (I forget now what) I came across the hecubafb and patterned
    >> the
    >> G13 after it instead.
    >>
    >> In moving between the two, the biggest difference was that I was able to
    >> strip out alot of the workqueue code you had since all that was provided
    >> by defio. Otherwise, the general structure was almost identical.
    >>
    >> In particular, what would change is the lower half of cfag12864b.c and
    >> you
    >> would be able to eliminate almost everything from the /* Update work */
    >> and below comment with the exception of cfag12864b_update().
    >>
    >> cfag12864b_update() would become almost analogous to the g13_fb_update()
    >> I
    >> have in the G13 driver which is triggered by the deferred_io member of
    >> the
    >> fb_deferred_io structure.
    >>
    >> You would have something like:
    >>
    >> /* Callback from deferred IO workqueue */
    >> static void cfag12864b_deferred_io(struct fb_info *info, struct
    >> list_head
    >> *pagelist)
    >> {
    >>        cfag12864b_update(info->par);
    >> }
    >>
    >> static struct fb_deferred_io cfag12864b_defio = {
    >>        .delay = HZ / CFAG12864B_UPDATE_RATE_DEFAULT,
    >>        .deferred_io = cfag12864b_deferred_io,
    >> };
    >>
    >
    > Thank you for the analysis of cfag12864b. See below.
    >
    >>
    >> The other major change is that you could eliminate the periodic memcmp()
    >> to see if the buffer has change since the deferred_io is only going to
    >> trigger on a page write fault.
    >
    > Yeah, I admit the memcmp() is pretty ugly knowing about deferred_io,
    > which I did not. It is strange that anyone pointed it out long before,
    > is it new? Are there any known drawbacks?
    >

    Not sure how old it is... I don't know of any drawbacks.

    >>
    >> But, that isn't a major change in the code... only in performance.
    >>
    >
    > So less code and greater performance. That sounds like a winning deal!
    >
    > About ks0108, have you got any thoughts on how to write a generic
    > driver? Do you need something special about ks0108? I only needed raw
    > output operations so I just implemented that. Also, cfag12864b uses
    > two ks0108 controllers and I suppose other LCD's use many more, so
    > there are many points that may need a "research".
    >

    Actually, I don't need the ks0108 code. Way back when Alan Cox suggested
    taking a framebuffer approach for the G13, Pavel suggested looking at the
    auxdisplay code.

    But, the LCD in the G13 is really a USB device that ships the image out as
    an interrupt message with the framebuffer image as the payload. So, in
    essence, the callback in the G13 is really a usbhid_submit_message() after
    some other work to massage the bits from an xbm format to a format
    specific to the Logitech game panel.

    ---

    Rick


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-01-15 00:05    [W:2.273 / U:2.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site