• Does the RPi 1B rev1 Framebuffer have hardware support for a mouse curs

    From R.Wieser@3:770/3 to All on Sun Jun 25 19:27:59 2023
    Hello all,

    I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
    no GUI of any kind.

    I ofcourse wanted to see if I could draw some graphics on it. :-)

    I've found that it supports a "Frame Buffer" onto which pixels can be
    plotted.

    I also found the "fb.h" include file, and was able to get FBIOCOPYAREA to
    work.

    Alas, thats as far as I got. Even though the file mentions hardware
    support for a mouse cursor I've not been able to get that to work. :-(

    The file also contains "fb_fillrect" structure, but doesn't show anything
    about how / where its used.

    tl;dr:
    I could use an example which shows how to use "_iowr()" to get the build-in mouse cursor to work, and would not mind at all if someone knows how to draw
    a simple rectangle using the same "_iowr()" method.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to R.Wieser on Sun Jun 25 22:00:52 2023
    R.Wieser <address@is.invalid> wrote:
    Hello all,

    I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
    no GUI of any kind.

    I ofcourse wanted to see if I could draw some graphics on it. :-)

    I've found that it supports a "Frame Buffer" onto which pixels can be plotted.

    I also found the "fb.h" include file, and was able to get FBIOCOPYAREA to work.

    Alas, thats as far as I got. Even though the file mentions hardware
    support for a mouse cursor I've not been able to get that to work. :-(

    The file also contains "fb_fillrect" structure, but doesn't show anything about how / where its used.

    RISC OS uses the GPU to draw its hardware pointer. Here's the code: https://gitlab.riscosopen.org/RiscOS/Sources/Video/HWSupport/BCMVideo/-/blob/master/s/HWPointer

    That appears to be using VCHIQ which is the service to send messages to the GPU:
    https://ultibo.org/wiki/Unit_VC4VCHIQ https://elinux.org/Raspberry_Pi_VideoCore_APIs

    RISC OS appears to be using the vc_dispman API to ask the GPU to draw the pointer.

    tl;dr:
    I could use an example which shows how to use "_iowr()" to get the build-in mouse cursor to work, and would not mind at all if someone knows how to draw a simple rectangle using the same "_iowr()" method.

    _iowr() is a basic 32-bit I/O write (ie write 32 bits to I/O address
    0x....).

    The GPU is several levels above this in the stack: you need to craft a
    message to ask the GPU to do it, using the appropriate API, and then ask something (/dev/vchiq on Linux) to deliver the message.

    There may be some support for this stuff in the RPi userland libraries: https://github.com/raspberrypi/userland/tree/master/interface
    but it's not immediately clear where it might be.

    Having said all this, you're on Linux not baremetal so I think a better way would be to use some existing library. I'd have a look at SDL as that might
    be easier to deal with (SDL 2 is '3D', SDL 1.2 is older and more 2D focused. You might be better starting with SDL 2 to begin with, even if you only want
    2D stuff). SDL is designed to be run either in a window or on a bare framebuffer style display.

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Theo on Mon Jun 26 09:45:24 2023
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    R.Wieser <address@is.invalid> wrote:
    tl;dr:
    I could use an example which shows how to use "_iowr()" to get the build-in >> mouse cursor to work, and would not mind at all if someone knows how to draw >> a simple rectangle using the same "_iowr()" method.

    _iowr() is a basic 32-bit I/O write (ie write 32 bits to I/O address
    0x....).

    The GPU is several levels above this in the stack: you need to craft a message to ask the GPU to do it, using the appropriate API, and then ask something (/dev/vchiq on Linux) to deliver the message.

    If the aim is to go the lowest-level route, then it is possible to
    send "mailbox" messages to the GPU's proprietary driver directly
    via /dev/mem, rather than via a driver. Broadcom's routines for
    this are here: https://github.com/raspberrypi/firmware/blob/master/opt/vc/src/hello_pi/hello_fft/mailbox.c

    The documentation for Broadcom's GPU firmware isn't public
    though, so you'd need to look at the code of an existing graphics
    driver to figure out how to use (some of?) it anyway.

    There may be some support for this stuff in the RPi userland libraries: https://github.com/raspberrypi/userland/tree/master/interface
    but it's not immediately clear where it might be.

    This is the best index that I'm aware of for the various GPU API
    options:
    https://forums.raspberrypi.com/viewtopic.php?f=67&p=1901014

    Having said all this, you're on Linux not baremetal so I think a better way would be to use some existing library. I'd have a look at SDL as that might be easier to deal with (SDL 2 is '3D', SDL 1.2 is older and more 2D focused. You might be better starting with SDL 2 to begin with, even if you only want 2D stuff). SDL is designed to be run either in a window or on a bare framebuffer style display.

    SDL 2 also has a "kmsdrm" driver which in theory might be faster
    than than the "directfb" framebuffer driver for SDL 1.2 and SDL 2.
    It uses the kernel's vc4 driver (note that there's a Mesa driver
    that's also called vc4), which presumably has some way of moving
    the mouse pointer with the GPU if that acceleration is normally
    used.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Mon Jun 26 09:51:32 2023
    Kev,

    If the aim is to go the lowest-level route,

    Not really. Currently I just want to get it to work thru the available
    "frame buffer" methods.

    The problem is that that "fb.h" file /looks/ to be saying such support is available, but I can't get it to work. As such at this point in time I
    would just like to know if its supported or not.

    I have no problem throwing another number of hours googeling at it trying to figure out what I did wrong and what I need to do instead, but would like to forgo the possibility that its simply not supported (and as such would just
    be wasting my time, getting more and more frustrated :-( ).

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Mon Jun 26 09:30:22 2023
    Theo,

    Having said all this, you're on Linux not baremetal so I think
    a better way would be to use some existing library.

    Which is why I mentioned the "fb.h" file and its mentioning of having a "_iowr()" function to set up such a cursor. I just can't seem to find
    enough info to be able to either get it to work or figure out if its unsupported. :-(

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to R.Wieser on Mon Jun 26 14:12:05 2023
    On 2023-06-25 19:27, R.Wieser wrote:
    Hello all,

    I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
    no GUI of any kind.

    I ofcourse wanted to see if I could draw some graphics on it. :-)

    I've found that it supports a "Frame Buffer" onto which pixels can be plotted.


    I got one of these
    pi@raspberrypi:~ $ cat /proc/cpuinfo
    processor : 0
    model name : ARMv6-compatible processor rev 7 (v6l)
    BogoMIPS : 697.95
    Features : half thumb fastmult vfp edsp java tls
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant : 0x0
    CPU part : 0xb76
    CPU revision : 7

    Hardware : BCM2835
    Revision : 000e
    Serial : 000000000304c6ef
    Model : Raspberry Pi Model B Rev 2
    pi@raspberrypi:~ $


    running

    pi@raspberrypi:~ $ cat /etc/os-release
    PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
    NAME="Raspbian GNU/Linux"
    VERSION_ID="10"
    VERSION="10 (buster)"
    VERSION_CODENAME=buster
    ID=raspbian
    ID_LIKE=debian
    HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
    pi@raspberrypi:~ $


    which uses the frambuffer - via SDL- via pygame

    I have this in the header - migth be valid urls still
    ""
    Pygame base template for opening a window

    Sample Python/Pygame Programs
    Simpson College Computer Science
    http://programarcadegames.com/
    http://simpson.edu/computer-science/

    Explanation video: http://youtu.be/vRB_983kUMc
    """





    I think the relevant part is ( edited and untested)

    import os
    import pygame


    def puts(what,size,x,y):
    font = pygame.font.SysFont("freserif", size)
    color = WHITE
    text = font.render(what, True, color)
    screen.blit(text, (x - text.get_width() // 2, \
    y - text.get_height() // 2))



    os.environ["SDL_FBDEV"] = "/dev/fb1"
    pygame.init()
    # Set the width and height of the screen [width, height]
    size = (320, 240)
    screen = pygame.display.set_mode(size)
    pygame.mouse.set_visible(0)
    done = False
    # -------- Main Program Loop -----------
    while not done:
    try:
    for event in pygame.event.get():
    if event.type == pygame.QUIT:
    done = True
    elif event.type == pygame.KEYDOWN \
    and event.key == pygame.K_ESCAPE:
    done = True

    # --- Game logic should go here

    # --- Screen-clearing code goes here

    screen.fill(BLACK)


    #get data to draw

    # --- Drawing code should go here
    puts(str(int(today['total'])), 150, 160, 60)
    puts(str(int(this_week['total'])), 75, 80, 140)
    puts(str(int(last_week['total'])), 75, 80, 200)
    puts(str(int(this_month['total'])), 75, 240, 140)
    puts(str(int(last_month['total'])), 75, 240, 200)
    # --- Go ahead and update the screen with what we've drawn.
    pygame.display.flip()



    pygame.quit()
    exit()


    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Mon Jun 26 15:28:51 2023
    Björn,

    I think the relevant part is ( edited and untested)

    [snip]

    Thank you for that code. But I'm looking for something a bit more low-level than that.

    I've already written most of what you have there in plain C, but would like
    to replace some of my own solutions with whats already available as part of
    the "frame buffer" support.

    Hardware instead of a software mouse pointer. Makes the drawing other stuff much easier. The mentioned _iowr() call to draw a (filled) rectangle
    instead of iterating over all the pixels myself. Perhaps other drawing
    stuff if available (lines ? (filled) circles ? Anything goes).

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to R.Wieser on Tue Jun 27 09:42:14 2023
    R.Wieser <address@is.invalid> wrote:
    Computer Nerd Kev wrote:
    If the aim is to go the lowest-level route,

    Not really. Currently I just want to get it to work thru the available "frame buffer" methods.

    The problem is that that "fb.h" file /looks/ to be saying such support is available, but I can't get it to work. As such at this point in time I would just like to know if its supported or not.

    OK right, you're talking about the Linux framebuffer rather than
    the GPU framebuffer, which the Linux framebuffer writes to. I see
    now that this is the fb.h file that you mean: https://github.com/torvalds/linux/blob/master/include/linux/fb.h

    I guess this is what you're interested in:
    /* Draws cursor */
    int (*fb_cursor) (struct fb_info *info, struct fb_cursor *cursor);

    I guess that _might_ be supported on the Pi via the KMS/DRM driver,
    but this suggests that it's at least possible for it not to use
    hardware acceleration: https://github.com/torvalds/linux/blob/master/drivers/video/fbdev/core/softcursor.c

    Maybe one of the results here is a good example of using the
    framebuffer cursor?
    https://codesearch.debian.net/search?q=fb_cursor

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Tue Jun 27 08:46:40 2023
    Kev,

    I see now that this is the fb.h file that you mean: https://github.com/torvalds/linux/blob/master/include/linux/fb.h

    Not quite the same one. Mine seems to be a bit simpler, and starts with :

    - - - - - - - - - - - - - - - - - - - -
    /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
    #ifndef _LINUX_FB_H
    #define _LINUX_FB_H

    #include <linux/types.h>
    #include <linux/i2c.h>

    /* Definitions of frame buffers */

    #define FB_MAX 32 /* sufficient for now */

    /* ioctls
    0x46 is 'F' */
    #define FBIOGET_VSCREENINFO 0x4600
    #define FBIOPUT_VSCREENINFO 0x4601
    - - - - - - - - - - - - - - - - - - - -

    I guess this is what you're interested in:
    /* Draws cursor */
    int (*fb_cursor) (struct fb_info *info, struct fb_cursor *cursor);

    Something like it :
    - - - - - - - - - - - - - - - - - - - -
    #define FBIO_CURSOR _IOWR('F', 0x08, struct fb_cursor)
    - - - - - - - - - - - - - - - - - - - -

    IOW, I've got the call and the struct(s) (a bit lower in the file), but am struggeling with filling the struct(s) with the correct data. Or maybe I
    have done that, but my Rpi simply doesn't support it. And I've got no idea
    how to check for the latter. Frustrating to say the least.

    I guess that _might_ be supported on the Pi via the KMS/DRM
    driver, but this suggests that it's at least possible for it
    not to use hardware acceleration: https://github.com/torvalds/linux/blob/master/drivers/video/fbdev/core/softcursor.c

    I found that one too, but as the name already suggests, that seems to be for
    an emulated mouse cursor. That one I already wrote myself. :-)

    And although I thought I could at least extract the method with which it
    draws stuff on the canvas, the part ending with "info->fbops->fb_imageblit(info, image);" has way to much stuf in there that
    I have no idea what exactly it is doing (using GCC here). :-|

    Maybe one of the results here is a good example of using the
    framebuffer cursor?
    https://codesearch.debian.net/search?q=fb_cursor

    Whoa, 26 pages of it ... That will take me quite some time to get thru it
    all, even when I skip the C++ snippets.

    Thanks for that, I don't think I've ever used that "codesearch" engine.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to R.Wieser on Tue Jun 27 21:30:43 2023
    R.Wieser <address@is.invalid> wrote:
    Kev,

    I see now that this is the fb.h file that you mean:
    https://github.com/torvalds/linux/blob/master/include/linux/fb.h

    Not quite the same one. Mine seems to be a bit simpler, and starts with :

    OK, this must be it: https://github.com/torvalds/linux/blob/master/include/uapi/linux/fb.h

    I guess this is what you're interested in:
    /* Draws cursor */
    int (*fb_cursor) (struct fb_info *info, struct fb_cursor *cursor);

    Something like it :
    - - - - - - - - - - - - - - - - - - - -
    #define FBIO_CURSOR _IOWR('F', 0x08, struct fb_cursor)
    - - - - - - - - - - - - - - - - - - - -

    IOW, I've got the call and the struct(s) (a bit lower in the file), but am struggeling with filling the struct(s) with the correct data. Or maybe I have done that, but my Rpi simply doesn't support it. And I've got no idea how to check for the latter. Frustrating to say the least.

    Yes, and not having programmed for the Linux framebuffer I can't
    help much myself. But the key thing is that this is the _Linux_
    framebuffer, not the hardware framebuffer. So it's hardware
    independent and there isn't a question over whether your RPi
    supports it. The same code writing to the Linux framebuffer should
    display on RPi, PC, or even on a custom display panel that
    someone's written a framebuffer driver for.

    I guess that _might_ be supported on the Pi via the KMS/DRM
    driver, but this suggests that it's at least possible for it
    not to use hardware acceleration:
    https://github.com/torvalds/linux/blob/master/drivers/video/fbdev/core/softcursor.c

    I found that one too, but as the name already suggests, that seems to be for an emulated mouse cursor. That one I already wrote myself. :-)

    You missed my point. That's in the framebuffer driver code, so when
    you do all this to move the cursor via the Linux framebuffer, the
    Linux kernel probably just runs that code to "emulate" a hardware
    mouse cursor in software. The framebuffer driver on the RPi isn't
    necessarily good enough to have implemented the hardware
    acceleration so you might be better off just using your own
    software mouse cursor code.

    I don't know how to rule in/out there being RPi hardware cursor
    support in the Linux source code. If it's there then it isn't
    obvious, but these things often aren't. Apparantly in 2014 it
    wasn't there, because this RPi software engineer published a
    modified version of the slightly-RPi-accelerated "fbturbo"
    framebuffer driver which added hardware mouse cursor support: https://forums.raspberrypi.com/viewtopic.php?t=65037&start=25#p490490

    Note that the thread ends before the matching GPU firmware binary
    was released. Did it get included in a later GPU firmware version,
    or was it abandoned? If the firmware wasn't released then the
    thread makes it clear that the hardware cursor didn't work without
    it.

    Or maybe it was released and supported somewhere in the main Linux
    framebuffer driver that's used now on the RPi. These mysteries are
    all too hard to figure out, so you'll have to do that yourself.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Computer Nerd Kev on Tue Jun 27 21:46:07 2023
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    I don't know how to rule in/out there being RPi hardware cursor
    support in the Linux source code. If it's there then it isn't
    obvious, but these things often aren't. Apparantly in 2014 it
    wasn't there, because this RPi software engineer published a
    modified version of the slightly-RPi-accelerated "fbturbo"
    framebuffer driver which added hardware mouse cursor support: https://forums.raspberrypi.com/viewtopic.php?t=65037&start=25#p490490

    Note that the thread ends before the matching GPU firmware binary
    was released. Did it get included in a later GPU firmware version,
    or was it abandoned? If the firmware wasn't released then the
    thread makes it clear that the hardware cursor didn't work without
    it.

    Or maybe it was released and supported somewhere in the main Linux framebuffer driver that's used now on the RPi. These mysteries are
    all too hard to figure out, so you'll have to do that yourself.

    Gah, I mixed up the kernel framebuffer driver and the X framebuffer
    driver (both called fbdev). fbturbo is the accelerated X
    framebuffer driver, and indeed the version with the accelerated
    cursor support was released and working with the GPU firmware in
    2014:
    https://forums.raspberrypi.com/viewtopic.php?t=69926

    So you can't use that fbturbo driver, but _if_ similar code is in
    the Linux kernel's RPi framebuffer driver somewhere then it might
    be used. If not, then you might as well draw the cursor with your
    own code (or use X if you really need the hardware acceleration).

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Tue Jun 27 15:07:11 2023
    Kev,

    But the key thing is that this is the _Linux_
    framebuffer, not the hardware framebuffer. So it's hardware
    independent and there isn't a question over whether your RPi
    supports it. The same code writing to the Linux framebuffer
    should display on RPi, PC, or even on a custom display panel
    that someone's written a framebuffer driver for.

    Don't be too sure about that. I've seen quite a number of implementations
    which only code is returning a constant value.

    You missed my point.
    ...
    The framebuffer driver on the RPi isn't necessarily good enough
    to have implemented the hardware acceleration so you might be
    better off just using your own software mouse cursor code.

    Thats the RPi doesn't have hardware support is quite possible, though the "fb.h" file seems to hit at it being present. As such the absense of any
    way to check (directly or indirectly) for supported features is ... not
    funny.

    Heck, I can't even seem to find any documentation on what the returned value means. And that /really/ bugs me.

    because this RPi software engineer published a modified version
    of the slightly-RPi-accelerated "fbturbo" framebuffer driver which
    added hardware mouse cursor support: https://forums.raspberrypi.com/viewtopic.php?t=65037&start=25#p490490

    I think I've come across that name too, but as with the other
    bits-and-pieces I found there does not seem to be any testing code around
    that shows its usage.

    I followed the link to james "hwcursor.c" code, and noticed its from 2014.
    In Rpi time thats pretty-much the stone age era (I'm using bullseye, which
    is rather recent).

    Or maybe it was released and supported somewhere in the main
    Linux framebuffer driver that's used now on the RPi. These
    mysteries are all too hard to figure out, so you'll have to
    do that yourself.

    :-) I /know/ its too hard to figure out for me, which is why I posted my question here.

    I think I'm going to throw the towel, and just assume that the only support
    my framebuffer has is copying something from one place on the screen to another, and that everything else - even if I've seen some of them marked as required - needs to be written yourself.

    Oh well. Thanks for the help.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Computer Nerd Kev on Tue Jun 27 15:06:45 2023
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    R.Wieser <address@is.invalid> wrote:
    Kev,

    I see now that this is the fb.h file that you mean:
    https://github.com/torvalds/linux/blob/master/include/linux/fb.h

    Not quite the same one. Mine seems to be a bit simpler, and starts with :

    OK, this must be it: https://github.com/torvalds/linux/blob/master/include/uapi/linux/fb.h

    The Pi kernel is a separate tree: https://github.com/raspberrypi/linux/blob/rpi-6.1.y/include/linux/fb.h
    that one looks quite different to the fb.h in mainline Linux.

    Yes, and not having programmed for the Linux framebuffer I can't
    help much myself. But the key thing is that this is the _Linux_
    framebuffer, not the hardware framebuffer. So it's hardware
    independent and there isn't a question over whether your RPi
    supports it. The same code writing to the Linux framebuffer should
    display on RPi, PC, or even on a custom display panel that
    someone's written a framebuffer driver for.

    The mainline fb.h looks full of 90s-era VGA-related stuff. There's some mention of ARM chips, but they're all 15+ years old.

    In general terms, many framebuffers don't support a hardware pointer -
    they're just dumb framebuffers after all. It looks like support has been
    added to the Pi version for that.

    The Pi hardware doesn't support a hardware pointer either, but AIUI the GPU handles drawing it for you. So it's effectively a fake hardware pointer,
    it's just drawn by something that isn't the OS.

    (traditionally, hardware pointers are drawn on top of the raster scanout.
    Here the GPU is doing a full image composite instead, so that's not really a 'hardware' pointer, it's just an API call to the GPU)

    You missed my point. That's in the framebuffer driver code, so when
    you do all this to move the cursor via the Linux framebuffer, the
    Linux kernel probably just runs that code to "emulate" a hardware
    mouse cursor in software. The framebuffer driver on the RPi isn't
    necessarily good enough to have implemented the hardware
    acceleration so you might be better off just using your own
    software mouse cursor code.

    I don't know how to rule in/out there being RPi hardware cursor
    support in the Linux source code. If it's there then it isn't
    obvious, but these things often aren't. Apparantly in 2014 it
    wasn't there, because this RPi software engineer published a
    modified version of the slightly-RPi-accelerated "fbturbo"
    framebuffer driver which added hardware mouse cursor support: https://forums.raspberrypi.com/viewtopic.php?t=65037&start=25#p490490

    SFAIK the RPi folks added the 'hardware cursor' support as GPU-side
    software, to support operating systems like RISC OS which are designed
    around a hardware pointer. For that (on bare metal) you use the GPU
    mailboxes to send a VCHIQ message to the GPU.

    I think FBIO_CURSOR in that fb.h file is a red herring: it's been there
    since 29 July 2004, which means the _IOWR is an I/O write that's nothing to
    do with the Pi, most likely related to some of the VGA-compatible hardware
    that was in use at the time. https://github.com/tbodt/linux-history/commit/53699287a25ea8c6d3a3f1b3404d8ebbcba6b580

    I think if you want to use this from modern Linux (not via this legacy framebuffer stuff) you need to interact with the DRM (direct rendering
    manager) kernel subsystem via the KMS (kernel mode setting) interface: https://en.wikipedia.org/wiki/Direct_Rendering_Manager

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Tue Jun 27 17:40:28 2023
    Theo,

    The Pi hardware doesn't support a hardware pointer either, but AIUI
    the GPU handles drawing it for you.

    Do you have any (example) code which tells the GPU to do that ? 'Cause I
    can't seem to find any (might be because I don't recognise it though :-| ).

    And if that is so, how does it work with frame buffer (memory) writes ? How does the {whatever} know when it should remove the fake cursor so the image beneath it can be altered ?

    Curently I have to disable (remove) my fake cursor before, and than enable (draw) it again after each action which changes the frame buffer memory.

    I think FBIO_CURSOR in that fb.h file is a red herring:

    I've gotten that feeling too.

    By the way, if you know any other frame buffer manipulation calls (draw (filled) rectangles and circles, draw an image, draw lines(?) ) I would like
    to hear about them. Even better if you happen to have a link to a Raspberry
    Pi specific documentation of it. :-)

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to R.Wieser on Tue Jun 27 23:25:33 2023
    R.Wieser <address@is.invalid> wrote:
    Theo,

    The Pi hardware doesn't support a hardware pointer either, but AIUI
    the GPU handles drawing it for you.

    Do you have any (example) code which tells the GPU to do that ? 'Cause I can't seem to find any (might be because I don't recognise it though :-| ).

    I think it would be somewhere in the vc_dispmanx APIs, but I'm not seeing it here:
    https://github.com/raspberrypi/userland/tree/master/interface/vmcs_host

    I pointed upthread to the RISC OS code which uses it, but that's not Linux.

    And if that is so, how does it work with frame buffer (memory) writes ?
    How does the {whatever} know when it should remove the fake cursor so the image beneath it can be altered ?

    It's composited on top by the GPU, ie the framebuffer has no cursor, the
    GPU draws the cursor on top of the framebuffer when the screen is
    composited. You just give the GPU a pointer to the cursor bitmap and the
    X/Y coordinates.

    By the way, if you know any other frame buffer manipulation calls (draw (filled) rectangles and circles, draw an image, draw lines(?) ) I would like to hear about them. Even better if you happen to have a link to a Raspberry Pi specific documentation of it. :-)

    Look at OpenVG which offers 2D graphics operations: https://en.wikipedia.org/wiki/OpenVG
    https://github.com/cboyer/openvg-rpi

    Supposedly OpenVG has been dropped from the Pi 4 (which uses a different GPU
    to 0/1/2/3). These days it's better to use 3D operations (eg OpenGL) for 2D drawing. There are some implementations of OpenVG on top of OpenGL: https://forums.raspberrypi.com/viewtopic.php?t=245380

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to R.Wieser on Wed Jun 28 09:19:10 2023
    R.Wieser <address@is.invalid> wrote:
    The Pi hardware doesn't support a hardware pointer either, but AIUI
    the GPU handles drawing it for you.

    Do you have any (example) code which tells the GPU to do that ? 'Cause I can't seem to find any (might be because I don't recognise it though :-| ).

    Well you said you already saw the fbturbo implementation: https://github.com/JamesH65/xf86-video-fbturbo/blob/master/src/raspi_hwcursor.c

    OK it's from 2014, but I doubt they would have changed the commands
    used by the GPU, and they're what matter.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Wed Jun 28 09:30:23 2023
    Kev,

    Well you said you already saw the fbturbo implementation:

    I did.

    OK it's from 2014, but I doubt they would have changed the
    commands used by the GPU, and they're what matter.

    The thing is that that is, AFAIK, what "frame buffer" support is build ontop of. With it doing some of the abstractions which would enable a program written using it to run on different hardware configurations.

    Going down a level from "frame buffer" support to using the "mailbox" way of sending commands is something I've not yet tried.

    Though I might try to rewrite all the "frame buffer" stuff I've currently
    got using that "mailbox" method. Who knows. Currently my focus is "frame buffer", trying to find out what exactly it offers me and how to use it.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to R.Wieser on Wed Jun 28 09:14:07 2023
    R.Wieser <address@is.invalid> wrote:
    Though I might try to rewrite all the "frame buffer" stuff I've currently
    got using that "mailbox" method. Who knows. Currently my focus is "frame buffer", trying to find out what exactly it offers me and how to use it.

    Traditionally, framebuffer is exactly that. A pointer to an W x H sized
    block of pixels, which is displayed on the screen. That's it. Nothing
    else. If you want to draw stuff on it, it's up to you to manipulate the pixels. If you want to double buffer, change the pointer to a different WxH block of pixels.

    Some graphics cards (eg VGA) have 'extra stuff' which know about things like fonts or pointers, but that's not the framebuffer, it's down to the VGA or other driver. In the Pi's case that's the VideoCore and the VCHIQ APIs, but they're not standard.

    So if you're looking for these things inside the framebuffer code you won't find them. If you do want more stuff you need to explore DRM/KMS (as a
    generic Linux kernel API) or VCHIQ (for Pi specific things).

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Wed Jun 28 09:08:15 2023
    Theo,

    I think it would be somewhere in the vc_dispmanx APIs, but I'm not seeing
    it here: https://github.com/raspberrypi/userland/tree/master/interface/vmcs_host

    I pointed upthread to the RISC OS code which uses it, but that's not
    Linux.

    I guess I could take a look and see if I can find any "frame buffer" calls
    in there ... Hmm, a quick look in all the .C files doesn't show any frame buffer related includes.

    It's composited on top by the GPU, ie the framebuffer has no cursor,
    the GPU draws the cursor on top of the framebuffer when the screen is composited.

    That suspiciously sounds like mouse pointer hardware support. :-)

    Look at OpenVG which offers 2D graphics operations:

    Thank you for the link. Though my current objective is to try to find out
    as much as I can about what "frame buffer" supports.

    At some point in the future I might just install OpenGL or alike and bin my
    own attempts to create something usefull, but today isn't the day.

    Hobbyists are weird : they can spend untold hours upon recreating what
    already exists (even in a better form) and see nothing wrong with it. I'm a hobby programmer. :-)

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Theo on Thu Jun 29 09:46:12 2023
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    R.Wieser <address@is.invalid> wrote:
    Though I might try to rewrite all the "frame buffer" stuff I've currently
    got using that "mailbox" method. Who knows. Currently my focus is "frame >> buffer", trying to find out what exactly it offers me and how to use it.

    Traditionally, framebuffer is exactly that. A pointer to an W x H sized block of pixels, which is displayed on the screen. That's it. Nothing
    else. If you want to draw stuff on it, it's up to you to manipulate the pixels. If you want to double buffer, change the pointer to a different WxH block of pixels.

    Exactly, and "traditionally" it's actually a hardware address for
    unaccelerated display of bitmaps via the graphics card. Accelerated
    things like the mouse cursor are done on top of this. The _Linux_
    framebuffer is a pretend version of that, so if any acceleration
    features did exist, they'd be sort-of a bonus, becuase they're not
    really the intention, which is a hardware-independent version on
    the physical framebuffer.

    Of course a look at the Framebuffer page on Wikipedia explains all
    this already.

    This is why I originally assumed that R.Wieser _was_ talking about
    the Pi's hardware framebuffer, instead of the Linux one. He still
    insists on not specifying which one he's talking about when talking
    about "the frame buffer stuff" in his posts. Somewhat frustrating.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Thu Jun 29 10:10:39 2023
    Kev,

    This is why I originally assumed that R.Wieser _was_ talking
    about the Pi's hardware framebuffer, instead of the Linux one.
    He still insists on not specifying which one he's talking about
    when talking about "the frame buffer stuff" in his posts.

    I had hoped that all the info I included in my first post would have cleared that up. You know, "fb.h", "_iowr()", "FBIOCOPYAREA" and "fb_copyarea".

    And thats besides the several times I tried to explain at what level I'm working at. Including the "With it doing some of the abstractions which
    would enable a program written using it to run on different hardware configurations." and "Though I might try to rewrite all the "frame buffer" stuff I've currently got using that "mailbox" method." that I wrote in my previous message.

    But to clear that confusion up, I am talking about the (what I /assume/ you mean with) "the linux one".

    A question tough : "the Pi's hardware framebuffer" ? As in the same thing with the same API/hardware adresses for *all* the different RPi versions ?
    In that case it could be worth some time to take a peek at it.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Thu Jun 29 09:44:36 2023
    Theo,

    Traditionally, framebuffer is exactly that. A pointer to an W x H
    sized block of pixels, which is displayed on the screen.

    That part I've got down. Drawing lines, (filled) rectangles, (filled) circles, clipping and a software mouse cursor. Still working at filled polygons. Convex works, concave takes some more work.

    The whole thing is that the "fb.h" file on my machine hints at support for a few things, like a hardware mouse cursor, drawing a (filled?) rectangle, drawing an image, panning the screen, copying one part of the screen to
    another part and a few others.

    IOW, the same include file which contains the declarations that are needed
    to be able to create access to such a user-land pixel memory also contains hints to support for other stuff. And the usage of that other stuff is
    what I'm currently trying to figure out.

    So if you're looking for these things inside the framebuffer code you
    won't find them.

    I already found them. In many implementations. Though some of them just contain "return -EINVAL;" for a number of the calls. :-|

    Currently all I'm doing is looking at the API - and only at a number of implementations to figure out how to use it.

    And thats also part of the problem : I have no idea which of those implementations is the one used by bullseye or even if its actually among
    them. If I had the code it would be rather easy to figure out what, and
    what isn't supported.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to R.Wieser on Thu Jun 29 21:28:28 2023
    R.Wieser <address@is.invalid> wrote:
    This is why I originally assumed that R.Wieser _was_ talking
    about the Pi's hardware framebuffer, instead of the Linux one.
    He still insists on not specifying which one he's talking about
    when talking about "the frame buffer stuff" in his posts.

    I had hoped that all the info I included in my first post would have cleared that up. You know, "fb.h", "_iowr()", "FBIOCOPYAREA" and "fb_copyarea".

    There's many a fb.h file out there, just do a web search and you'll
    see. Code found by searching for "fb.h raspberry pi" is mostly
    working with the hardware framebuffer, rather than the Linux one.
    Either way I wasn't going to read every fb.h that I could find just
    to see whether the contents matched all the symbols you happened to
    mention.

    If you'd provided a link, or the full path where it was installed
    by a RPi OS package, in the first post, then there needn't have
    been any guessing.

    A question tough : "the Pi's hardware framebuffer" ? As in the same thing with the same API/hardware adresses for *all* the different RPi versions ?
    In that case it could be worth some time to take a peek at it.

    Like the GPIO and other peripherals, different versions have
    different physical addresses for the different Pis. RPi 1 and Zero
    uses a base address of 0x20000000. RPI 2, 3, and Zero 2 is
    0x3F000000. That changes the addresses for the mailbox registers as
    shown in register maps.

    For the framebuffer itself, the GPU will actually allocate an area
    of memory for it upon request and tell you the starting address
    that it's chosen. As such you have to assume that the address might
    be different every time you initialise it, and use the pointer it
    gives you via the mailbox interface (but you need to convert it
    from a bus address (0x7E000000) to a physical address (as above)).

    https://elinux.org/RPi_Framebuffer

    The RPi 4 GPU is VideoCore VI, rather than VideoCore IV for the
    other Pis. I don't know much about it. Most docs don't seem to have
    been updated to cover it yet.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Thu Jun 29 14:49:13 2023
    Kev,

    There's many a fb.h file out there,

    And you never thought of trying to match it up with the device this
    newsgroup is for ? <surprised face>

    If you'd provided a link,

    You mean as I pretty-much did at Tue, 27 Jun 2023 08:46:40 +0200 in message <u7e0l1$1auoe$1@dont-email.me> ?

    or the full path where it was installed by a RPi OS package, in
    the first post, then there needn't have been any guessing.

    you mean the first line in my initial post where I said :

    [quote]
    I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
    no GUI of any kind.
    [/quote]

    As for the path ? Why would you need that ? I provided the name "fb.h" there too, and with it should be easy to find. On my system there is only one.

    A question tough : "the Pi's hardware framebuffer" ? As in the same
    thing with the same API/hardware adresses for *all* the different RPi
    versions ?
    In that case it could be worth some time to take a peek at it.

    Like the GPIO and other peripherals, different versions have
    different physical addresses for the different Pis.

    My apologies, I see I could have been a bit more precise : AFAIK I have to *ask* the RPi for a/the (hardware) framebuffer, and than map it into user space. After it is mapped you have to use the address returned by that mapping function - just as for the 'linux" framebuffer. Am I wrong there ?

    My question was aimed at if the place to send such requests to and the
    format of those requests is the same for all RPi versions.

    In fact, that is the problem I tried to evade by limiting myself (for the moment) to the "linux" framebuffer. I took it that if differences would be there than that API would handle them.

    Full disclosure : I've been programming direct (basic) hardware since
    forever, and only got taken that outof my hands by Windows (where I wasn't permitted direct access to it anymore). :-|

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to R.Wieser on Fri Jun 30 09:21:47 2023
    R.Wieser <address@is.invalid> wrote:
    There's many a fb.h file out there,

    And you never thought of trying to match it up with the device this
    newsgroup is for ? <surprised face>

    Now this is getting silly, but I'll repeat the bit you snipped
    from my last post:

    Code found by searching for "fb.h raspberry pi" is mostly
    working with the hardware framebuffer, rather than the Linux one.

    If you'd provided a link,

    You mean as I pretty-much did at Tue, 27 Jun 2023 08:46:40 +0200 in message <u7e0l1$1auoe$1@dont-email.me> ?

    No, not provide an extract, a link/path. It happened to be that I
    could do a web search on a bit of that and found out that you were
    using a "fb.h" header file provided by Linux. There was no
    indication of that earlier in the thread, so I assumed that fb.h
    was from one of the hardware framebuffer libraries seeing as you
    were talking about hardware acceleration.

    or the full path where it was installed by a RPi OS package, in
    the first post, then there needn't have been any guessing.

    you mean the first line in my initial post where I said :

    [quote]
    I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
    no GUI of any kind.
    [/quote]

    As for the path ? Why would you need that ? I provided the name "fb.h" there too, and with it should be easy to find. On my system there is only one.

    How do I know your system? It may be "bullseye lite", but I assume
    you've installed and downloaded other things onto it, and you never
    said you were using fb.h from Linux so it could easily be from
    some library or other that you've installed via a package or source
    code download. The path would have answered that.

    Anyway I've seen others have similar arguments with you about being
    unclear in your questions on Usenet, so I guess it's pointless.

    A question tough : "the Pi's hardware framebuffer" ? As in the same
    thing with the same API/hardware adresses for *all* the different RPi
    versions ?
    In that case it could be worth some time to take a peek at it.

    Like the GPIO and other peripherals, different versions have
    different physical addresses for the different Pis.

    My apologies, I see I could have been a bit more precise : AFAIK I have to *ask* the RPi for a/the (hardware) framebuffer, and than map it into user space. After it is mapped you have to use the address returned by that mapping function - just as for the 'linux" framebuffer. Am I wrong there ?

    That's correct.

    My question was aimed at if the place to send such requests to and the
    format of those requests is the same for all RPi versions.

    "The place to send such requests" is the mailbox peripheral, and
    the format is the same for the all the VideoCore IV Pis, which
    currently means all the models except maybe those based on the Pi
    4, which uses VideoCore VI (different GPU hardware, so many things
    changed, maybe including how the framebuffer works).

    In fact, that is the problem I tried to evade by limiting myself (for the moment) to the "linux" framebuffer. I took it that if differences would be there than that API would handle them.

    Sometimes you try to avoid a hassle only to create another one.
    Using the Linux Framebuffer but still wanting some hardware
    acceleration might be such a case.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Fri Jun 30 11:30:04 2023
    Kev,

    Code found by searching for "fb.h raspberry pi" is mostly
    working with the hardware framebuffer, rather than the Linux
    one.

    I noticed the same. I also noticed that most of the returned results had little, if anything, to do with an RPi. In short : for someone like me
    who's searching for something *relevant to the RPi* its next to worthless,
    as info pertaining to the RPi is seldom-if-ever marked as such, and thus
    drowns in a series of codesamples all allmost, but not exactly the same. :-(

    ... and thats while already having ignored "results" like "the nearest baker
    to you" and similar crap.

    Or, in other words: I have not been able to find "linux frame buffer" code relevant to the RPi. If I would have I could rather likely have spotted if
    the hardware cursor would be supported or not, and which other basic graphic actions (rectangle, image, etc) would be available - and by inspecting how
    the implementation of them handles their arguments be able to figure out how
    to invoke them.

    ... and I would never have posted here ...

    No, not provide an extract, a link/path. It happened to be that
    I could do a web search on a bit of that and found out that you
    were using a "fb.h" header file provided by Linux.

    Ah, you wanted me to find the same file on the internet and so that way you could look at it yourself. It would have been a good idea to tell me that.

    As for that "you were using a "fb.h" header file provided by Linux." ?
    Even with just the info I supplied in my initial post (or just looking at
    the subjectline of this thread!) /what else/ would I have been using than
    Linux ?

    How do I know your system? It may be "bullseye lite", but I assume
    you've installed and downloaded other things onto it,

    It would have been a good idea to verify that with me, 'cause no, I haven't.
    As such your assumption just made your task more difficult for you than need be, and as a result more difficult for me.

    I had no idea why you would ask me for that path when you do not seem to run
    an RPi (with bullseye), and as such would be unable to inspect that file.

    ... Which is why I posted the first few lines of it, so you could see that
    your and my files where not equal.

    Anyway I've seen others have similar arguments with you about being
    unclear in your questions on Usenet, so I guess it's pointless.

    And I've seen you being unclear in what you needed from me, so I guess we
    are on an equal footing there.

    As for "Unclear in your question" accusations ? Funny that those only turn
    up way down in a thread, and never are preceeded by any kind of "I don't
    quite get the question, can you explain {this} or {that}". IOW, mostly
    coming from people who didn't understand (for whatever reason) the question, ultimatily getting told of (by me) for it, and than try to make it sound as
    if its my fault.

    My question was aimed at if the place to send such requests to and
    the format of those requests is the same for all RPi versions.

    "The place to send such requests" is the mailbox peripheral, and
    the format is the same for the all the VideoCore IV Pis, which
    currently means all the models except maybe those based on the Pi
    4, which uses VideoCore VI (different GPU hardware, so many things
    changed, maybe including how the framebuffer works).

    Thank you. As said, that is enough for me to make it worth while to spend time writing "mailbox" stuff for it.

    Sometimes you try to avoid a hassle only to create another one.

    If I could only see into the future, than I would just know when to pursue a certain avenue and when to switch to another ...

    But as we cannot that ofcourse works the other way around as well - trying
    to avoid a (non existing?) hassle and by it find yourself in (an even
    bigger) one. IOW, you do not have a point here.

    And I do not want to be blunt here, but the /only/ "hassle" I have is the absense of basic documentation.

    Using the Linux Framebuffer but still wanting some hardware
    acceleration might be such a case.

    And I could have known that the "linux framebuffer" does not have any such support (even though it strongly hints to it) before this thread ... how exactly ?

    Also, I suggest you (re?)read the subjectline and/or my initial post. In it
    I made it quite clear that I was inquiring about *if* such support is
    available for the RPi, and *if* it is how to use it.

    And this is your next "hassle" you have assumed yourself into : what makes
    you think that I would like to mix up the linux framebufer with something
    else (mailbox), just to get a hardware mouse pointer ? To me that was at
    the moment of writing, a strict or-or situation.

    ... But now you've suggested it I might just see if it 1) can be done 2) is
    a workable solution. Why ? Why not.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to R.Wieser on Fri Jun 30 21:23:08 2023
    R.Wieser <address@is.invalid> wrote:
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    How do I know your system? It may be "bullseye lite", but I assume
    you've installed and downloaded other things onto it,

    It would have been a good idea to verify that with me, 'cause no, I haven't.
    [snip]
    As for "Unclear in your question" accusations ? Funny that those only turn up way down in a thread, and never are preceeded by any kind of "I don't quite get the question, can you explain {this} or {that}". IOW, mostly coming from people who didn't understand (for whatever reason) the question, ultimatily getting told of (by me) for it, and than try to make it sound as if its my fault.

    In my opinion your questions are often too hard to interpret
    correctly.

    Maybe someone would ask back 100 yes/no questions including "have
    you ever installed a package on your "bullseye lite" RPi 1B rev1?",
    and somehow receive the answer "no", before attempting an actual
    answer, but not me.

    Especially because I doubt you're understanding me either - you must
    have installed a compiler in your "bullseye lite" at least.

    Sometimes you try to avoid a hassle only to create another one.

    If I could only see into the future, than I would just know when to pursue a certain avenue and when to switch to another ...

    Sorry, "you" wasn't supposed to be personal. I meant we all do
    that, myself frequently included. I'm just making the point that
    the "easy way" with the Linux framebuffer might actually be harder
    if you want hardware acceleration. Or maybe there is h/w mouse
    acceleration hiding somewhere in the kernel's framebuffer driver?
    As I've said, I don't know for sure.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Fri Jun 30 16:21:31 2023
    Kev,

    In my opinion your questions are often too hard to interpret
    correctly.

    Than you are very welcome to ask for clarification.

    But be honest, look at the subjectline and tell me that that is a difficult question.

    Maybe someone would ask back 100 yes/no questions

    A single question to start with would have been enough : "did you install
    any packages".

    Especially because I doubt you're understanding me either - you must
    have installed a compiler in your "bullseye lite" at least.

    Thats another assumption with which you have created a new hassle for
    yourself. I understood your question quite well. I said I didn't install
    any packages and I haven't. The GCC compiler came as part of the "bullseye lite" OS package.

    And isn't including a GCC (or alike) into an OS package quite common ?

    Sometimes you try to avoid a hassle only to create another one.

    If I could only see into the future, than I would just know when to
    pursue a
    certain avenue and when to switch to another ...

    Sorry, "you" wasn't supposed to be personal.

    I know. But as you posted it to me ...

    If you want you can replace the "I"s I used with "we"s. It doesnt make any difference.

    I'm just making the point that the "easy way" with the Linux framebuffer might actually be harder if you want hardware acceleration.

    How, and even /why/ do you think so ?

    You've been able to look in that "fb.h" file. In it is the call as well as
    the arguments definition. It looks quite easy to me.

    And no, that its not supported(?) by BullsEye's linux framebuffer has no bearing on that.

    Besides, the same goes here : it /might/, but it could as easily be another method (the "mailbox" one?) which could turn out to be harder.

    In short, you've succumbed to FUD. Don't. All it does is freezing you, not allowing you to try (and learn!) /anything/.


    As an example, I wrote a software mouse cursor before even posting here.
    Which I'm sure is harder than just activating a hardware one. I still wrote it, if only to find out how complex / much work it actually is. It turns
    out its not reallly either.

    ... But I still wanted to know how the other, hardware method works - so I
    can compare, learn and have a choice.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Fri Jun 30 12:51:19 2023
    On Fri, 30 Jun 2023 16:21:31 +0200, "R.Wieser" <address@is.invalid>
    declaimed the following:


    But be honest, look at the subjectline and tell me that that is a difficult >question.


    It is if one does not know /which/ flavor of framebuffer is in play. A minimal software buffer where all drawing is done by setting bits using user-level software and which periodically gets blitted to the display hardware; one that is "owned" by a GPU that responds to drawing commands specific to the GPU (and in the case of the R-Pi, Broadcom releases very
    little documentation on its GPU -- one probably has to pay a small fortune
    and sign NDAs to get those details)?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Fri Jun 30 20:11:46 2023
    Dennis,

    But be honest, look at the subjectline and tell me that that is a
    difficult question.

    It is if one does not know /which/ flavor of framebuffer is in play.

    For which I posted additional information in my initial post, which
    combination of name and usage I presumed /should/ have allowed anyone to
    figure it out. You know, OS version, name of include file, way of calling, argument names.

    But if that was the whole problem than where am I asked for that flavor ? I would have tried to figure it out (probably with the askers help) and
    reported it.

    Making the responders life easier gives me a better chance at getting a
    usable answer. But I have to understand the question as much as you guys
    need to.


    By the way, its impossible for me fully respond to your "question", as I
    have no idea what you exactly mean by "flavor". The "linux" vs. hardware framebuffer ? Other versions of the linux framebuffer (or even hardware framebuffer!) ? Something else ? I like strawberry myself. :-)

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Computer Nerd Kev on Sat Jul 1 10:56:11 2023
    R.Wieser <address@is.invalid> wrote:
    not@telling.you.invalid (Computer Nerd Kev) wrote:
    Maybe someone would ask back 100 yes/no questions

    A single question to start with would have been enough : "did you install
    any packages".

    Nope, you could have downloaded fb.h manually from the web, so I'd
    need to ask that too.

    [you don't have to answer these questions - they're an example for
    how you could make your future first posts less ambiguous]

    Also to be sure I should have asked the full name/version of the OS
    because "bullseye lite" refers to a Debian release - "Bullseye".
    Theo assumed that you were talking about Raspberry Pi OS, but
    officially its versions are named after dates, eg. the latest would
    be "Raspberry Pi OS Lite 2023-05-03".

    RPi OS's latest versions are based on Debian Bullseye. But by that
    logic, to be sure I should also ask that it's the official
    Raspberry Pi OS Lite, not another distro derrived from it.

    I should have asked what programming language you were using. It
    was a C header, but you could have been using/preferring C++ or
    any another language that has bindings to C.

    I should have asked if you only wanted your program to run on the
    RPi 1B rev1, or whether compatibility with other RPi models
    mattered as well.

    I should have asked whether software compatibility with other
    non-RPi platforms mattered as well.

    Maybe I should have asked whether you were running the OS in a
    virtual environment, just in case you're actually running an
    x86 emulator in QEMU so that you can run x86 Debian Bullseye,
    and want to pass the mouse acceleration through all the layers of
    Linux/QEMU framebuffer emulation?

    I could go on, but the conclusion is obvious: I shouldn't bother
    answering your questions if you expect me to resolve every single
    point of uncertainty rather than assuming that you use RPis in a
    common way, or that you would have pointed out anything that is
    uncommon in your first post. Like trying to use hardware
    acceleration via the Linux framebuffer not the hardware framebuffer
    (which combined with all the other ambiguities made it seem likely
    that you were talking about the hardware framebuffer, not the Linux framebuffer).

    Especially because I doubt you're understanding me either - you must
    have installed a compiler in your "bullseye lite" at least.

    Thats another assumption with which you have created a new hassle for yourself. I understood your question quite well. I said I didn't install any packages and I haven't. The GCC compiler came as part of the "bullseye lite" OS package.

    Oh, OK. I remember needing to install lots of compiling tools before
    compiling software I wrote in RPi OS Lite, but maybe GCC wasn't one
    of those after all.

    And isn't including a GCC (or alike) into an OS package quite common ?

    No, in minimal/lite releases of Debian and other popular Linux
    distros GCC usually needs to be installed manually from the package
    repo. It's not typically in the installation image/package because
    only a sub-set of users ever compile software.

    I'm just making the point that the "easy way" with the Linux framebuffer
    might actually be harder if you want hardware acceleration.

    How, and even /why/ do you think so ?

    You've been able to look in that "fb.h" file. In it is the call as well as the arguments definition. It looks quite easy to me.

    And no, that its not supported(?) by BullsEye's linux framebuffer has no bearing on that.

    Besides, the same goes here : it /might/, but it could as easily be another method (the "mailbox" one?) which could turn out to be harder.

    In short, you've succumbed to FUD. Don't. All it does is freezing you, not allowing you to try (and learn!) /anything/.

    As an example, I wrote a software mouse cursor before even posting here. Which I'm sure is harder than just activating a hardware one. I still wrote it, if only to find out how complex / much work it actually is. It turns
    out its not reallly either.

    ... But I still wanted to know how the other, hardware method works - so I can compare, learn and have a choice.

    Good, my concern was only that you would stick at the Linux
    framebuffer now and ignore the hardware one simply because the
    Linux one looked easier _before_ you realised that it wasn't
    properly documented and didn't "just work" for hardware mouse
    acceleration. An unfounded concern, perhaps.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Sat Jul 1 09:32:33 2023
    Kev,

    A single question to start with would have been enough : "did you
    install any packages".

    Nope, you could have downloaded fb.h manually from the web, so I'd
    need to ask that too.

    And what would you need to do after you downloaded it ?

    [you don't have to answer these questions - they're an example
    for how you could make your future first posts less ambiguous]

    If I would know that they where ambiguous than I would already have tried to dis-ambiguate them.

    Otherwise I would just have posted "the cursor doesn't work. Help." (as subjectline and contents) (just imagine the drool coming outof the corner of
    my mouth) and let you guys have a go at figuring out what the heck I might
    mean with it.

    Also to be sure I should have asked the full name/version of the OS
    because "bullseye lite" refers to a Debian release - "Bullseye".
    Theo assumed that you were talking about Raspberry Pi OS, but
    officially its versions are named after dates, eg. the latest would
    be "Raspberry Pi OS Lite 2023-05-03".

    Answer : this is the RPi newsgroup. Take your "guess" which version I might
    be referring to. IOW, don't be daft.

    I should have asked what programming language you were using. It
    was a C header, but you could have been using/preferring C++ or
    any another language that has bindings to C.

    If you where doubting for any reason I would not be using the default programming language for an RPI you could surely have asked for it.

    But somehow I don't really think that the used programming language dictates what the API is supporting. IOW, don't be daft.

    I should have asked if you only wanted your program to run on
    the RPi 1B rev1, or whether compatibility with other RPi models
    mattered as well.

    I take it that you have neither read my subjectline or my initial message,
    as both specify what I was after. Any second-guessing to what I "actually" ment in that regard is your own problem. IOW, don't be daft.

    I should have asked whether software compatibility with other
    non-RPi platforms mattered as well.

    While posting in an RPi forum ? And naming a specific hardware platform ?
    I would have considered you to be an idiot. IOW, its good that you didn't.

    Maybe I should have asked whether you were running the OS in
    a virtual environment, just in case you're actually running
    an x86 emulator in QEMU so that you can run x86 Debian Bullseye,
    and want to pass the mouse acceleration through all the layers of
    Linux/QEMU framebuffer emulation?

    I suggest you (re)read my initial posts "tl;dr" part.

    I could go on, but the conclusion is obvious: I shouldn't bother
    answering your questions if you expect me to resolve every single
    point of uncertainty rather than assuming that you use RPis in a
    common way,

    Funny, you expect me to resolve all of *YOUR* points of uncertanty before
    you have even expressed them, while most all of that uncertainty comes from assuming I've done all kinds of uncomon things and have applied alterations without me even mentioning that I did.

    Yes, I expect you, when no modifier is supplied, to assume the default -
    unless you get a strong hint to that I might be using something else. If we (and I stress that "we") cannot do that than any kind of conversation
    becomes effectivily inpossible.

    Good, my concern was only that you would stick at the Linux framebuffer
    now and ignore the hardware one simply because the Linux one looked easier

    Really ? When I've mentioned a few times now that my whole goal was to
    learn how to use that API ?

    _before_ you realised that it wasn't properly documented and didn't
    "just work" for hardware mouse acceleration.

    I already knew it wasn't properly documented. If it would have been my multi-hour (days) "googeling" would have found it, or someone actually using it. I found neither.

    Hence my posting here.

    An unfounded concern, perhaps.

    Perhaps. Though I must say that my eagerness to also figure that "mailbox" method out has been tampered by knowing that if I need to ask a question
    about it I will probably experience something similar as what we have now.

    Besides, I think that that "mailbox" method /might/ be harder, and you have told me not to bother with such "might be harder" things. Aren't you glad
    that I, for once, heed your advice ? :-)

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Bill Findlay@3:770/3 to R.Wieser on Sat Jul 1 20:56:00 2023
    On 1 Jul 2023, R.Wieser wrote
    (in article <u7op6j$2shgi$1@dont-email.me>):

    Perhaps. Though I must say that my eagerness to also figure that "mailbox" method out has been tampered by knowing that if I need to ask a question about it I will probably experience something similar as what we have now.

    Besides, I think that that "mailbox" method /might/ be harder, and you have told me not to bother with such "might be harder" things. Aren't you glad that I, for once, heed your advice ? :-)

    Regards,
    Rudy Wieser

    Rudy, you have discovered how helpful this newsgroup is
    and how welcoming to newcomers looking for guidance!

    --
    Bill Findlay
    Free software contributor since 1976. Incompetent googler and "Usenet leech" (c.s.r-pi dixit).

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Sat Jul 1 17:00:56 2023
    On Sat, 1 Jul 2023 09:32:33 +0200, "R.Wieser" <address@is.invalid>
    declaimed the following:

    If you where doubting for any reason I would not be using the default >programming language for an RPI you could surely have asked for it.


    As a learning device for embedded computers, the "default programming language" pushed by the R-Pi foundation is... PYTHON

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to R.Wieser on Sun Jul 2 07:36:54 2023
    On Sun, 25 Jun 2023 19:27:59 +0200
    "R.Wieser" <address@is.invalid> wrote:

    Hello all,

    I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
    no GUI of any kind.

    I ofcourse wanted to see if I could draw some graphics on it. :-)

    I've found that it supports a "Frame Buffer" onto which pixels can be plotted.

    I also found the "fb.h" include file, and was able to get FBIOCOPYAREA to work.

    As far as I know hardware mouse support is something that may or
    may not exist depending on the underlying implementation of the framebuffer device. I did come across this presentation with links to a lot of software using the framebuffer which you may find useful.

    <https://archive.fosdem.org/2020/schedule/event/fbdev/attachments/slides/3595/export/events/attachments/fbdev/slides/3595/fosdem_2020_nicolas_caramelli_linux_framebuffer.pdf>

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    Host: Beautiful Theory meet Inconvenient Fact
    Obit: Beautiful Theory died today of factual inconsistency

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Sun Jul 2 09:35:03 2023
    Ahem,

    As far as I know hardware mouse support is something that may or
    may not exist depending on the underlying implementation of the
    framebuffer device.

    Yep, that is as far as got too.

    I did come across this presentation with links to a lot of
    software using the framebuffer which you may find useful. <https://archive.fosdem.org/2020/schedule/event/fbdev/attachments/slides/3595/export/events/attachments/fbdev/slides/3595/fosdem_2020_nicolas_caramelli_linux_framebuffer.pdf>

    Thank you.

    I had a quick peek at it (first few pages) and it looks promising. Lets
    hope I can find some example/test code in there, answering the "does or
    doesn't it" question conclusively.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Sun Jul 2 09:06:46 2023
    Bill,

    Rudy, you have discovered how helpful this newsgroup is
    and how welcoming to newcomers looking for guidance!

    Well, they /did/ try to respond. I have to give them that.

    But as I often get it, somewhere along the road the question and its
    supporting information gets forgotten and the responses veer off into chaos.
    A veering off Which than later, for some reason, becomes my fault. :-(

    It also doesn't help that I've got a number of years of experience with
    usenet, computers and programming, which means that I'm not much of a
    push-over anymore (as you might have noticed :-) ).

    Regards,
    Rudy Wieser

    P.s.
    Sadly enough, nonwithstanding the length of this thread, I literally do not know anything more about the frame buffer API than when I posted the
    question.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Sun Jul 2 09:36:03 2023
    Dennis,

    As a learning device for embedded computers, the "default
    programming language" pushed by the R-Pi foundation is... PYTHON

    :-) I know a series of "learning programming devices" (often
    microcontroller based), and they all have their own preferred scripting language. Some even using pictograms instead of words.

    However, the default programming language for *Linux* still seems to be C,
    with most
    often GCC as its compiler.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to R.Wieser on Wed Jul 5 16:46:47 2023
    On 02/07/2023 08:36, R.Wieser wrote:
    Dennis,

    As a learning device for embedded computers, the "default
    programming language" pushed by the R-Pi foundation is... PYTHON

    :-) I know a series of "learning programming devices" (often
    microcontroller based), and they all have their own preferred scripting language. Some even using pictograms instead of words.

    However, the default programming language for *Linux* still seems to be C, with most
    often GCC as its compiler.

    And a little Rust now creeping in.
    And the dreaded C++ shite
    Regards,
    Rudy Wieser




    --
    If I had all the money I've spent on drink...
    ..I'd spend it on drink.

    Sir Henry (at Rawlinson's End)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jan Panteltje@3:770/3 to address@is.invalid on Thu Jul 6 10:26:26 2023
    On a sunny day (Tue, 27 Jun 2023 17:40:28 +0200) it happened "R.Wieser" <address@is.invalid> wrote in <u7evtp$1eabv$1@dont-email.me>:

    Theo,

    The Pi hardware doesn't support a hardware pointer either, but AIUI
    the GPU handles drawing it for you.

    Do you have any (example) code which tells the GPU to do that ? 'Cause I >can't seem to find any (might be because I don't recognise it though :-| ).

    And if that is so, how does it work with frame buffer (memory) writes ? How >does the {whatever} know when it should remove the fake cursor so the image >beneath it can be altered ?

    Curently I have to disable (remove) my fake cursor before, and than enable >(draw) it again after each action which changes the frame buffer memory.

    I think FBIO_CURSOR in that fb.h file is a red herring:

    I've gotten that feeling too.

    By the way, if you know any other frame buffer manipulation calls (draw >(filled) rectangles and circles, draw an image, draw lines(?) ) I would like >to hear about them. Even better if you happen to have a link to a Raspberry >Pi specific documentation of it. :-)

    Regards,
    Rudy Wieser

    Not sure where the problem is,
    I use things like this:
    https://panteltje.nl/panteltje/xgpspc/index.html
    runs on the oldest Pi I have,
    uses libX11
    compiles on raspi:

    See X11.c
    You can gate mouse position see
    get_pointer()
    do_mouse()
    And draw anything anywhere you like
    Basically write stuff to xbuffer.
    Same code also runs on X86 back to before year 2000.


    simpler:
    https://panteltje.nl/panteltje/mcamip/index.html
    look at the Makefiles
    LIBRARY = -L/usr/lib/arm-linux-gnueabihf -lXaw -lXext -lX11 -lXt -ljpeg -lm

    Hope this helps.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Thu Jul 6 14:36:30 2023
    Jan,


    Not sure where the problem is,

    I just want to know how to use the "linux frame buffer" API myself. The problem is that somehow some people have a problem understanding that.

    After that I can always install another something which will give me even easier graphics access. But that will than probably be OpenGL. Supports 3D too.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jan Panteltje@3:770/3 to address@is.invalid on Thu Jul 6 15:05:53 2023
    On a sunny day (Thu, 6 Jul 2023 14:36:30 +0200) it happened "R.Wieser" <address@is.invalid> wrote in <u86cgt$u6s7$1@dont-email.me>:

    Jan,


    Not sure where the problem is,

    I just want to know how to use the "linux frame buffer" API myself. The >problem is that somehow some people have a problem understanding that.

    After that I can always install another something which will give me even >easier graphics access. But that will than probably be OpenGL. Supports 3D >too.

    Regards,
    Rudy Wieser

    OK, I have used OpenGL myself for some thing, used code from here:
    https://www.codemiles.com/c-opengl-examples/

    You could perhaps look at the source of libxt:
    https://gitlab.freedesktop.org/xorg/lib/libxt
    or source of xlib

    I did something long ago writing directly to a graphics card hardware,
    then modified the routines for xlib, for xvtx-p:
    https://panteltje.nl/panteltje/satellite/xvtx-p-0.1.1.tgz
    is that wat you want:
    screenshot:
    https://panteltje.nl/pub/xvtx-p-nl_now.gif

    From the code:
    Display *mydisplay;

    void s3plot(int x, int y, int color)/*plot 1 dot*/
    {
    static int previouscolor;
    /* avoid 're appearing' at left and top */
    if(x >= HSIZE)return;
    if(y >= VSIZE)return;
    if(color != previouscolor)
    {
    XSetForeground(mydisplay, xptestgc, color);
    previouscolor = color;
    }
    /* XSetBackground(mydisplay, xptestgc, WHITE);*/
    XDrawPoint(mydisplay, topwindow, xptestgc, x, y);
    https://tronche.com/gui/x/xlib/graphics/drawing/XDrawPoint.html
    ?
    https://www.x.org/releases/current/doc/libX11/libX11/libX11.html

    OK have fun!
    Found it fun to program all that stuff in the late nineties.

    Hardware support .. why bother, frame is updated many times per second.
    cursor is just a few pixels...
    ?
    delete old pixels draw a new one... in the buffer.


    xvtx-p has a nice hand like cursor..

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Thu Jul 6 21:43:08 2023
    Jan,

    Hardware support .. why bother, frame is updated many times
    per second. cursor is just a few pixels...?

    delete old pixels draw a new one... in the buffer.

    The thing is that drawing on the canvas is simpler (and faster) if the mousepointer doesn't need to be removed every time I want to change a pixel under it.

    But don't worry, I wrote a (minimal, basic) software solution even before posting here.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to R.Wieser on Fri Jul 7 08:55:10 2023
    R.Wieser <address@is.invalid> wrote:
    Jan,


    Not sure where the problem is,

    I just want to know how to use the "linux frame buffer" API myself. The problem is that somehow some people have a problem understanding that.

    At least now you're specifying which frame buffer you mean when you
    use that term in your posts. What irked me before was that you
    didn't do so even after the problems with understanding had arisen.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Fri Jul 7 10:02:05 2023
    Kev,

    At least now you're specifying which frame buffer you mean

    Only after someone told me that that was the one I most likely ment with all
    my initialy given information (I'm still wondering how some, given that
    info, could have assumed I would be referring to another one, hardware or otherwise.).

    What irked me before was that you didn't do so even after
    the problems with understanding had arisen.

    At some point you understood which one I ment, but you still needed me to
    call it by its full name instead of the short one ? That sounds like your problem, not mine.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From mm0fmf@3:770/3 to The Natural Philosopher on Fri Jul 7 09:59:02 2023
    On 07/07/2023 09:48, The Natural Philosopher wrote:
    On 07/07/2023 09:02, R.Wieser wrote:
    Kev,

    At least now you're specifying which frame buffer you mean

    Only after someone told me that that was the one I most likely ment
    with all
    my initialy given information (I'm still wondering how some, given that
    info, could have assumed I would be referring to another one, hardware or
    otherwise.).

    What irked me before was that you didn't do so even after
    the problems with understanding had arisen.

    At some point you understood which one I ment, but you still needed me to
    call it by its full name instead of the short one ?   That sounds like
    your
    problem, not mine.

    That depends on if it is you that wants help...

    Regards,
    Rudy Wieser




    Typical Rudy behaviour.

    He doesn't want help he wants a argument.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to R.Wieser on Fri Jul 7 09:48:24 2023
    On 07/07/2023 09:02, R.Wieser wrote:
    Kev,

    At least now you're specifying which frame buffer you mean

    Only after someone told me that that was the one I most likely ment with all my initialy given information (I'm still wondering how some, given that
    info, could have assumed I would be referring to another one, hardware or otherwise.).

    What irked me before was that you didn't do so even after
    the problems with understanding had arisen.

    At some point you understood which one I ment, but you still needed me to call it by its full name instead of the short one ? That sounds like your problem, not mine.

    That depends on if it is you that wants help...

    Regards,
    Rudy Wieser



    --
    The New Left are the people they warned you about.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)