Why do not CRT/LCD monitors come with USB? - Hardware

This is a discussion on Why do not CRT/LCD monitors come with USB? - Hardware ; In article , anon wrote: > In , ebenZEROONE@verizon.net (Hactar) writes: > >In article , > >anon wrote: > >> > >> In , ebenZEROONE@verizon.net (Hactar) writes: > >> >In article , > >> >anon wrote: > >> >> What ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 39 of 39

Thread: Why do not CRT/LCD monitors come with USB?

  1. Re: Why do not CRT/LCD monitors come with USB?

    In article <7gXgk.128537$102.15822@bgtnsc05-news.ops.worldnet.att.net>,
    anon wrote:
    > In , ebenZEROONE@verizon.net (Hactar) writes:
    > >In article ,
    > >anon wrote:
    > >>
    > >> In , ebenZEROONE@verizon.net (Hactar) writes:
    > >> >In article ,
    > >> >anon wrote:
    > >> >> What Drivers?
    > >> >
    > >> >Of course there are drivers. What do you think's on the volume it
    > >> >offers you the first time you connect to it? You think your computer
    > >> >will automatically know what to do with device #XXXX/#YYYY whenever
    > >> >it shows up?
    > >> >
    > >> The version I was talking about, allows the computer owner to choose any
    > >> video card they want and that apart device just plugs into it. The
    > >> other part plugs into any monitor that you want. Basically you could say
    > >> it act like an wireless extension for the video cable.

    > >
    > >So your device still uses a driver to a video card, and something
    > >proprietary gets shoved down the USB cable.
    > >

    > The first version does not use USB it uses the RGB signals only.


    What makes the RGB signals, some hardware? Bet that hardware has a
    driver. "Software you already have" != "no software".

    --
    There's a term for those who fantasize that the world works in
    precisely the way that produces maximum convenience for them,
    despite years of evidence to the contrary. The term is "Morons".
    GA in

  2. Re: Why do not CRT/LCD monitors come with USB?

    Todays camera may or may not have a software driver. And back in the 80s
    sat receiver / CD / VCR were non cpu also. Even the first DVDs were non
    cpu. And, today those devices that are still non-cpu, do not have a
    software driver.

    TROLL!!!


    In , ebenZEROONE@verizon.net (Hactar) writes:
    >In article <7gXgk.128537$102.15822@bgtnsc05-news.ops.worldnet.att.net>,
    >anon wrote:
    >> In , ebenZEROONE@verizon.net (Hactar) writes:
    >> >In article ,
    >> >anon wrote:
    >> >>
    >> >> In , ebenZEROONE@verizon.net (Hactar) writes:
    >> >> >In article ,
    >> >> >anon wrote:
    >> >> >> What Drivers?
    >> >> >
    >> >> >Of course there are drivers. What do you think's on the volume it
    >> >> >offers you the first time you connect to it? You think your computer
    >> >> >will automatically know what to do with device #XXXX/#YYYY whenever
    >> >> >it shows up?
    >> >> >
    >> >> The version I was talking about, allows the computer owner to choose any
    >> >> video card they want and that apart device just plugs into it. The
    >> >> other part plugs into any monitor that you want. Basically you could say
    >> >> it act like an wireless extension for the video cable.
    >> >
    >> >So your device still uses a driver to a video card, and something
    >> >proprietary gets shoved down the USB cable.
    >> >

    >> The first version does not use USB it uses the RGB signals only.

    >
    >What makes the RGB signals, some hardware? Bet that hardware has a
    >driver. "Software you already have" != "no software".
    >
    >--
    >There's a term for those who fantasize that the world works in
    >precisely the way that produces maximum convenience for them,
    >despite years of evidence to the contrary. The term is "Morons".
    > GA in



  3. Re: Why do not CRT/LCD monitors come with USB?

    On Wed, 16 Jul 2008 03:32:38 +0200 (CEST) david wrote:
    | On Wed, 16 Jul 2008 01:17:57 +0000, Rahul rearranged some electrons to
    | say:
    |
    |> These days, every possible accessory seems to be "bluetooth" / USB
    |> interfaced. But I've never seen a "USB" monitor advertised. (neither
    |> bluetooth, of course) Neither CRT (who buys those!? ) nor LCD.
    |>
    |> Why is that? A bandwidth limitation? Or a need that doesn't exist? I
    |> doubt that is the reason since if I can want a USB headset why not a USB
    |> monitor?
    |>
    |> Besides there are "good" quality headsets available even on bluetooth.
    |> Is "acceptable-quality" sound transmission fundamentally a lower
    |> bandwidth process than "acceptable-quality" images? What is the ratio of
    |> the max bandwidth attainable over USB vs bluetooth vs
    |> "traditional-monitor- connections".
    |>
    |> I cannot think of any other peripheral that isn't available in a USB
    |> version if not bluetooth. Do others have examples of they know? Just
    |> curious....
    |
    | Example for a medium resolution:
    |
    | 1024 x 768 pixels x 24 bits per pixel x 30 frames per second
    | = 566 Mbits/sec.
    |
    | USB 2.0 high speed = 480 Mbits/sec

    That's for the old model of retransmitting every bit over and over and over
    faster than you can see it change.

    USB (or Firewire or ethernet) might well be practical if the video model is
    changed to where the monitor acts like a VNC client and the traffic across
    the wire represents only what is updated most of the time (and occaisionally
    a full refresh can be made in case of lost pixels).

    That might not do so well for those HD 1920 x 1080 at 60 Hz progressive TV
    sports programs. But it would be fine for 99% of office desktop uses and
    99% of non-video home computer uses.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  4. Re: Why do not CRT/LCD monitors come with USB?

    In comp.os.linux.hardware Paul wrote:

    | This monitor has a USB2.0 interface to drive the video display
    | (as well as the more ordinary and higher bandwidth interfaces).
    | It uses a compressed data stream, to compensate for the limitations
    | of USB2 bandwidth.
    |
    | http://www.everythingusb.com/samsung...0ux_11970.html

    And what kind of support for this exists in Linux? X? DirectFB?


    | It wouldn't be fair or meaningful, to compare DVI to those two. But just
    | for kicks, a single link DVI uses three diff pairs RGB with data streams on them.
    | At a so-called 165MHz clock, each diff pair runs at 1650 megabits/sec, or
    | a total of 4950 megabits/sec. Dual link uses two instances of the interface,
    | for double that bandwidth (but dual link is not commonly used for your
    | average cheap LCD monitor). Just to offer some perspective with respect
    | to USB2.0.

    And even dual-link DVI won't be able to handle what is coming in the future
    of video and TV (10+ years from now). Be prepared for a video display device
    that can do extreme video, but takes its input in VNC (for desktop) or MPEG
    (for video) formats over whatever connection medium is available as long as
    it is fast enough. Ideally the display can have both at the same time, with
    VNC providing the base layout, and MPEG for a specific video feed that can
    be directed to whatever region of the display is desired (or the whole screen)
    with the HDCP decoding done in the display, where needed. Then the OS only
    has to layout the screen and pass the stream (which would be two way between
    the display and video source when HDCP is involved).

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  5. Re: Why do not CRT/LCD monitors come with USB?

    On Wed, 16 Jul 2008 08:26:31 +0100 "M.I.5?" wrote:
    |
    | "Rahul" wrote in message
    | news:Xns9ADCCE2A53BF66650A1FC0D7811DDBC81@85.214.9 0.236...
    |> These days, every possible accessory seems to be "bluetooth" / USB
    |> interfaced. But I've never seen a "USB" monitor advertised. (neither
    |> bluetooth, of course) Neither CRT (who buys those!? ) nor LCD.
    |>
    |> Why is that? A bandwidth limitation? Or a need that doesn't exist? I doubt
    |> that is the reason since if I can want a USB headset why not a USB
    |> monitor?
    |>
    |> Besides there are "good" quality headsets available even on bluetooth. Is
    |> "acceptable-quality" sound transmission fundamentally a lower bandwidth
    |> process than "acceptable-quality" images? What is the ratio of the max
    |> bandwidth attainable over USB vs bluetooth vs "traditional-monitor-
    |> connections".
    |>
    |> I cannot think of any other peripheral that isn't available in a USB
    |> version if not bluetooth. Do others have examples of they know? Just
    |> curious....
    |>
    |
    | It is perfect feasible to run a computer display via the USB interface (and
    | there are examples of this in practice). However, having said that, the USB
    | interface is far from an ideal choice for the job. The biggest limitations
    | are the limited bandwidth and that the host USB port (the one on the PC)
    | requires a considerable amount of CPU support when transmitting and
    | receiving data. Since this will be happening more or less continuously, the
    | CPU will have difficulty finding enough time for all the other activities
    | that it has to support. In general, it is most desireable to take as much
    | of the graphic functions away from the main CPU as possible. This is why
    | PCs have a dedicated Graphics Processor with its own dedicated interface
    | with the monitor. Then the CP can get on with doing what it does best.

    We need a new kind of interface. Existing ones like USB, Firewire, and SATA,
    were designed for specific purposes original and were, or will be, repurposed
    for other things. That's really not very good design. Something that is
    designed to allow _any_ kind of devide from the outset, with _standard_
    protocols included for a large variety of device uses (only ONE driver is
    needed for any one class of device, regardless of manufacturer or model),
    all designed with the future in mind for things like expanding to higher
    and higher bandwidths, metal and optical medium, hermaphroditic connectors,
    and multi-lane options. IMHO, this needs to be part of the redesign of the
    PC internal bus as well (PCIe is only partly headed in the right direction).
    Ultimately a SoC chip would have RAM internal and this interface coming out
    directly for a very tiny but powerful machine (no more north and south bridge
    and other mainboard bulkiness).

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  6. Re: Why do not CRT/LCD monitors come with USB?

    On Wed, 16 Jul 2008 20:05:21 +0200 Henrik Carlqvist wrote:
    | Rahul wrote:
    |> Is sound processing as a rule "cheaper" than video?
    |
    | Yes. Remember the good old days when audio was stored on compact casettes
    | and also video was stored on VHS tapes? If I remember right the compact
    | audio tape casette was a lot smaller than a VHS video tape.
    |
    | Today the physical size isn't such an obvious difference. A CD for music
    | has exactly the same size as a DVD which stores video. However, the CD and
    | the DVD are completely different media and if you compare those media when
    | it comes to storing data you will find that an audio CD usually stores
    | data equvalent to about 700 MB. A dual layer video DVD is capable to store
    | about 8 GB which is more than ten times as much as the audio CD.
    |
    | The audio CD can contain up to 80 minutes of uncompressed sound sampled at
    | 44.1 kHz with 16 bits per sample.
    |
    | The DVD typically contains up to two hours of video and sound, but then
    | the video as well as the sound is heavily compressed with different mpeg
    | technologies.
    |
    | If you use such compressions technologies on an audio CD you
    | can burn your music as mp3 files. Doing so you will find that you can
    | easily put ten times as much music on a single CD.

    However, the handling of these devices has not been uniform. For example
    a DVD player that can also play audio CDs, including MP3 CDs (CD in data
    format with MP3 files in an ISO filesystem), is NOT able to handle those
    same MP3 files in the new ISO filesystem used on all DVDs).

    Ideally a device should treat all media it gets in a uniform way (but CD
    audio format is a forced exception), and support every filessytem it knows
    how to support on every media it can support, along with every file format.
    So if the player has an SDHC flash memory card, it can handle everything on
    the memory card that it could handle on any CD or DVD. If it has a USB
    port, it can handle anything on a USB flash key or a USB RAID hub that has
    a dozen 1TB drives plugged in (that would be a LOT of music or video or
    picture slide shows, etc).


    | So in short, video takes about 100 times as much bandwidt as audio and
    | then we are still only looking at TV resolution which is something like
    | 720x576 at 25 Hz. Today a 24 inch computer monitor has a typical
    | resolution of 1920x1200 pixels and is typically updated in 60 Hz. Compared
    | to the TV resolution this increases bandwidth with yet another factor of
    | about 10.

    Compressed video takes less. Over the air TV (USA) is 19.39 megabits per second
    and can put noth only both audio and video in there, but multiple subchannels
    of it. I know of at least 2 TV stations running one HD channel and two SD
    channels over their 19.39 mbps data stream. Now this MPEG2 compression, and
    the better MPEG4 compression that isn't used on over the air TV but is used in
    other places, isn't what is good for a workstation desktop display. But for
    that we can use the VNC protocol (or a better version of it). Add the ability
    to feed both a VNC stream and an MPEG stream, with instructions on what part
    of the screen each stream is displayed in (overlayed), and you get the best
    of both and support pixel perfect computer application display and TV grade
    video at the same time (even in a window).

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  7. Re: Why do not CRT/LCD monitors come with USB?

    On Sat, 19 Jul 2008 10:19:36 -0400 Hactar wrote:
    | In article <1Wdgk.246063$SV4.187976@bgtnsc04-news.ops.worldnet.att.net>,
    | anon wrote:
    |>
    |> In , Rahul
    |> writes:
    |> >These days, every possible accessory seems to be "bluetooth" / USB
    |> >interfaced. But I've never seen a "USB" monitor advertised. (neither
    |> >bluetooth, of course) Neither CRT (who buys those!? ) nor LCD.
    |> >
    |> >Why is that? A bandwidth limitation? Or a need that doesn't exist? I doubt
    |> >that is the reason since if I can want a USB headset why not a USB monitor?
    |>
    |> But the primary reason I believe is the industry knows there are other
    |> ways to send the audio(two-way stereo) and video(one-way sd/hd)
    |> without use of USB/Bluetooth. These devices are available and price
    |> is reasonable for the SD version and they do not require drivers, so
    |> they can be use with any system or monitor. Version have been
    |> available for over 25 years, but most people do not use them.
    |>
    |> Also, a direct video connection is faster. And with the move to HD
    |> monitors the bandwidth may become to great for a USB and other USB
    |> devices to maintain an error-free data transfer. Or do you want artifacts
    |> in both your monitor or camera.
    |
    | And then some "genius" will have the idea of implementing proprietary
    | data compression in the driver, and we'll have "Winmonitors".

    The key is for open standards groups to do it first. When they have failed
    to be "on the ball" then we get propritary junk.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  8. Re: Why do not CRT/LCD monitors come with USB?

    phil-news-nospam@ipal.net writes:
    >
    > We need a new kind of interface. Existing ones like USB, Firewire, and SATA,
    > were designed for specific purposes original and were, or will be,
    > repurposed


    Ummm, USB? USB most definitely designed from the ground up to be used
    for a wide variety of devices.

    > for other things. That's really not very good design. Something that is
    > designed to allow _any_ kind of devide from the outset, with _standard_
    > protocols included for a large variety of device uses (only ONE driver is
    > needed for any one class of device, regardless of manufacturer or
    > model),


    A compliant USB device of a particular class can be used with a
    generic driver. The device may implement additional functionality
    which requires a special driver, but core functionality can be
    accessed without it (yes, I know Windows tends to not realize this.
    That's not a weakness in USB).

  9. Re: Why do not CRT/LCD monitors come with USB?

    phil-news-nospam@ipal.net wrote:

    > Henrik Carlqvist wrote:
    > | The audio CD can contain up to 80 minutes of uncompressed sound sampled at
    > | 44.1 kHz with 16 bits per sample.
    > |
    > | The DVD typically contains up to two hours of video and sound, but then
    > | the video as well as the sound is heavily compressed with different mpeg
    > | technologies.


    The above finally resulted in a conclusion that as a rule of thumb
    computer graphics needs about 1000 times as much bandwidth compared to
    computer sound.

    > | If you use such compressions technologies on an audio CD you
    > | can burn your music as mp3 files. Doing so you will find that you can
    > | easily put ten times as much music on a single CD.
    >
    > However, the handling of these devices has not been uniform. For example
    > a DVD player that can also play audio CDs, including MP3 CDs (CD in data
    > format with MP3 files in an ISO filesystem), is NOT able to handle those
    > same MP3 files in the new ISO filesystem used on all DVDs).


    That is a choise that some manufacturers have done. Other brands are
    capable of playing mp3 files from DVD media.

    > | So in short, video takes about 100 times as much bandwidt as audio and
    > | then we are still only looking at TV resolution which is something
    > | like 720x576 at 25 Hz. Today a 24 inch computer monitor has a typical
    > | resolution of 1920x1200 pixels and is typically updated in 60 Hz.
    > | Compared to the TV resolution this increases bandwidth with yet
    > | another factor of about 10.


    > Compressed video takes less. Over the air TV (USA) is 19.39 megabits
    > per second and can put noth only both audio and video in there, but
    > multiple subchannels of it.


    Yes, with destructive compression algorithms like mpeg it is possible to
    lower the need for bandwidth. However, in those 19.39 Megabits per second,
    how many Megabits are used for audio and how many Megabits are used for
    video? Without knowing the true answer I would guess that aout 0.12
    Megabits per second are used for audio and the remaining 19.27 Megabits
    per second are used for video. So we still have a factor of more than 150
    for a video resolution far below what a 24" computer monitor can handle
    and a refresh rate which is about half the refresh rate you would expect
    on a computer monitor.

    > Now this MPEG2 compression, and the better MPEG4 compression that isn't
    > used on over the air TV but is used in other places, isn't what is good
    > for a workstation desktop display. But for that we can use the VNC
    > protocol (or a better version of it). Add the ability to feed both a
    > VNC stream and an MPEG stream, with instructions on what part of the
    > screen each stream is displayed in (overlayed), and you get the best of
    > both and support pixel perfect computer application display and TV grade
    > video at the same time (even in a window).


    These are some interesting thoughts that probably would result in
    something useful for most users. However, some users running heavy
    graphical simulations or playing games like first person shooters would
    probably suffer from bandwidth limitations and/or distorted images with
    such a solution using USB to transfer video.

    regards Henrik
    --
    The address in the header is only to prevent spam. My real address is:
    hc3(at)poolhem.se Examples of addresses which go to spammers:
    root@localhost postmaster@localhost


  10. Re: Why do not CRT/LCD monitors come with USB?

    Henrik Carlqvist wrote in
    newsan.2008.07.25.22.11.34.267953@deadspam.com:

    > These are some interesting thoughts that probably would result in
    > something useful for most users. However, some users running heavy
    > graphical simulations or playing games like first person shooters would
    > probably suffer from bandwidth limitations and/or distorted images with
    > such a solution using USB to transfer video.
    >


    Consider surfing the internet: All the "data" travels to my PC using a Wi-
    Fi internet connection (low-bandwidth?) I wonder what the bandwidth ratio
    would be. AVI connection with respect to WiFi. The processor definately
    bloated the information-stream before pushing it to my monitor and added
    redundancy absent in the incoming stream that could have been more
    effeciently resolved at monitor level. Even if I were watching a resonably
    high-def. Netflix streaming movie...

    ....just a thought!

    --
    Rahul

  11. Re: Why do not CRT/LCD monitors come with USB?

    On Sat, 26 Jul 2008 00:11:34 +0200 Henrik Carlqvist wrote:
    | phil-news-nospam@ipal.net wrote:
    |
    |> Henrik Carlqvist wrote:
    |> | The audio CD can contain up to 80 minutes of uncompressed sound sampled at
    |> | 44.1 kHz with 16 bits per sample.
    |> |
    |> | The DVD typically contains up to two hours of video and sound, but then
    |> | the video as well as the sound is heavily compressed with different mpeg
    |> | technologies.
    |
    | The above finally resulted in a conclusion that as a rule of thumb
    | computer graphics needs about 1000 times as much bandwidth compared to
    | computer sound.

    That can depend on how fast it changes. If it is a static screen, it
    would not take nearly as much. If the sound were one or a few steady
    sine waves that, too, would take a lot less (compressed).


    |> | If you use such compressions technologies on an audio CD you
    |> | can burn your music as mp3 files. Doing so you will find that you can
    |> | easily put ten times as much music on a single CD.
    |>
    |> However, the handling of these devices has not been uniform. For example
    |> a DVD player that can also play audio CDs, including MP3 CDs (CD in data
    |> format with MP3 files in an ISO filesystem), is NOT able to handle those
    |> same MP3 files in the new ISO filesystem used on all DVDs).
    |
    | That is a choise that some manufacturers have done. Other brands are
    | capable of playing mp3 files from DVD media.

    Or maybe not considering the design in a fluid modular way.


    |> Now this MPEG2 compression, and the better MPEG4 compression that isn't
    |> used on over the air TV but is used in other places, isn't what is good
    |> for a workstation desktop display. But for that we can use the VNC
    |> protocol (or a better version of it). Add the ability to feed both a
    |> VNC stream and an MPEG stream, with instructions on what part of the
    |> screen each stream is displayed in (overlayed), and you get the best of
    |> both and support pixel perfect computer application display and TV grade
    |> video at the same time (even in a window).
    |
    | These are some interesting thoughts that probably would result in
    | something useful for most users. However, some users running heavy
    | graphical simulations or playing games like first person shooters would
    | probably suffer from bandwidth limitations and/or distorted images with
    | such a solution using USB to transfer video.

    Yes, the gamers would need a much higher bandwidth pathway. Maybe a HDMI at
    500 MHz x 32 lanes?

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  12. Re: Why do not CRT/LCD monitors come with USB?

    On Thu, 24 Jul 2008 11:36:44 -0600 Joe Pfeiffer wrote:

    | phil-news-nospam@ipal.net writes:
    |>
    |> We need a new kind of interface. Existing ones like USB, Firewire, and SATA,
    |> were designed for specific purposes original and were, or will be,
    |> repurposed
    |
    | Ummm, USB? USB most definitely designed from the ground up to be used
    | for a wide variety of devices.

    It started as an interface to attach phones. Then it was added on to do
    a few computer input devices. It wasn't until USB 2.0 that speed finally
    became practical for things like disk storage.

    USB had to completely change the way the OS drivers worked to go to 2.0.
    It wasn't simply a case of being faster within the same protocol. It had
    to change the protocol, too. The next speed higher will require a new
    protocol.

    A better design would be an interface between driver and hardware that just
    goes faster when the hardware can deliver faster. The driver gives the
    command to send a message and in the newer faster model, the interrupt for
    completion of command comes back sooner. The meta registers that tell the
    driver what speed would have a HUGE range capacity (like a 64-bit number)
    beyond anyone's imagination.

    USB also slows down substantially through hubs. It can't keep data moving
    along and switch it in the hub at the same time.

    USB device addressing is flaky in design. Plug in a disk, unplug it, then
    plug the same disk back in to the same port, and it has a different address.

    USB is not very graceful in hotplugging. It can't figure out what is going
    on instantly. Firewire beats USB big time, and even Firewire is poor.


    |> for other things. That's really not very good design. Something that is
    |> designed to allow _any_ kind of devide from the outset, with _standard_
    |> protocols included for a large variety of device uses (only ONE driver is
    |> needed for any one class of device, regardless of manufacturer or
    |> model),
    |
    | A compliant USB device of a particular class can be used with a
    | generic driver. The device may implement additional functionality
    | which requires a special driver, but core functionality can be
    | accessed without it (yes, I know Windows tends to not realize this.
    | That's not a weakness in USB).

    So why does the old OHCI driver not "just work" at faster speeds when a faster
    USB port is used with a faster device? Why are there different drivers.

    When 3200 bps USB comes out, will the same existing driver work even at the
    new speed?

    Yes, there are standards for many devices on USB. But there still appear to
    be a number of issues. Maybe manufacturers (like Seagate) just don't do USB
    right? Why even give such leeway? Apparently there is a lack of specification
    on disk drive spin down in USB.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  13. Re: Why do not CRT/LCD monitors come with USB?

    In phil-news-nospam@ipal.net:

    [Snip...]

    > Yes, there are standards for many devices on USB. But there still appear
    > to be a number of issues.


    FWIW, I too have been very disappointed in USB over many years now. For a
    time I thought it was typical FOSS quirks (proprietary drivers bias). But
    over time I realized it wasn't always peachy keen outside FOSS, either.

    When I got my parents a printer for their Linux system, I ignored all USB
    offerings. Instead, we got a great HP parallel port laser printer, for 40
    bucks at a 2nds store. No complaints about that HP printer, years now.

    Same when they went on DSL; I was adamant with tech support that RJ45 was
    on the modem (*NOT* USB only). When the modem arrived, I plugged the RJ45
    jack up, and within 15 minutes had DSL running fine.

    To me, USB was always a solution in search of a problem, when the problem
    already had perfectly adequate "legacy" solutions readily evailable.

    About the only USB I do regularly now: thumbdrives for backups/xfers.

    JMO; YMMV...

    --
    Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
    Pardon any bogus email addresses (wookie) in place for spambots.
    Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
    I toss GoogleGroup posts from gitgo (http://improve-usenet.org).

  14. Re: Why do not CRT/LCD monitors come with USB?

    On Sat, 26 Jul 2008 02:19:09 +0000, Rahul typed this message:

    > Henrik Carlqvist wrote in
    > newsan.2008.07.25.22.11.34.267953@deadspam.com:
    >
    >> These are some interesting thoughts that probably would result in
    >> something useful for most users. However, some users running heavy
    >> graphical simulations or playing games like first person shooters would
    >> probably suffer from bandwidth limitations and/or distorted images with
    >> such a solution using USB to transfer video.
    >>
    >>

    > Consider surfing the internet: All the "data" travels to my PC using a
    > Wi- Fi internet connection (low-bandwidth?) I wonder what the bandwidth
    > ratio would be. AVI connection with respect to WiFi. The processor
    > definately bloated the information-stream before pushing it to my
    > monitor and added redundancy absent in the incoming stream that could
    > have been more effeciently resolved at monitor level. Even if I were
    > watching a resonably high-def. Netflix streaming movie...
    >
    > ...just a thought!


    Yep I agree. Forget about USB connectors. I'd like to see wireless
    monitors and audio.

  15. Re: Why do not CRT/LCD monitors come with USB?

    phil-news-nospam@ipal.net writes:

    > On Thu, 24 Jul 2008 11:36:44 -0600 Joe Pfeiffer wrote:
    >
    > | phil-news-nospam@ipal.net writes:
    > |>
    > |> We need a new kind of interface. Existing ones like USB, Firewire, and SATA,
    > |> were designed for specific purposes original and were, or will be,
    > |> repurposed
    > |
    > | Ummm, USB? USB most definitely designed from the ground up to be used
    > | for a wide variety of devices.
    >
    > It started as an interface to attach phones. Then it was added on to do
    > a few computer input devices. It wasn't until USB 2.0 that speed finally
    > became practical for things like disk storage.


    Huh? That's the first time I've ever seen anything even resembling
    that claim. It was intended for exactly what it's good at: replacing
    interfaces for things like keyboards, mice, and printers. Do you have
    a cite?

    > USB had to completely change the way the OS drivers worked to go to 2.0.
    > It wasn't simply a case of being faster within the same protocol. It had
    > to change the protocol, too. The next speed higher will require a new
    > protocol.


    But it is just a case of being faster within the same protocol.
    It's true that there's an extra negotiation required to go to
    hi-speed, but once you're there it's the same protocol. I'd have to
    spend more time than I want to to see whether the driver stack was
    re-written at the same the EHCI driver was added.

    > A better design would be an interface between driver and hardware that just
    > goes faster when the hardware can deliver faster. The driver gives the
    > command to send a message and in the newer faster model, the interrupt for
    > completion of command comes back sooner. The meta registers that tell the
    > driver what speed would have a HUGE range capacity (like a 64-bit number)
    > beyond anyone's imagination.


    So long as the hardware can reliabily report what that speed is...

    > USB also slows down substantially through hubs. It can't keep data moving
    > along and switch it in the hub at the same time.


    I'm not aware of anything in the protocol that makes wormhole routing
    impossible...

    > USB device addressing is flaky in design. Plug in a disk, unplug it, then
    > plug the same disk back in to the same port, and it has a different address.


    Whether that's flaky is a matter of opinion -- the intent is that a
    non-savvy user can unplug a disk, plug it into a different port, and
    have the OS recognize it's the same disk. To do that, you have to
    decouple the device addressing from the port it's plugged into; once
    you've done that, there's no reason to treat same-port as a special
    case.

    > USB is not very graceful in hotplugging. It can't figure out what is going
    > on instantly. Firewire beats USB big time, and even Firewire is poor.


    Most of that time is just allowing the device to settle.

    >
    > |> for other things. That's really not very good design. Something that is
    > |> designed to allow _any_ kind of devide from the outset, with _standard_
    > |> protocols included for a large variety of device uses (only ONE driver is
    > |> needed for any one class of device, regardless of manufacturer or
    > |> model),
    > |
    > | A compliant USB device of a particular class can be used with a
    > | generic driver. The device may implement additional functionality
    > | which requires a special driver, but core functionality can be
    > | accessed without it (yes, I know Windows tends to not realize this.
    > | That's not a weakness in USB).
    >
    > So why does the old OHCI driver not "just work" at faster speeds when a faster
    > USB port is used with a faster device? Why are there different drivers.


    Because the old OHCI (and UHCI) devices didn't talk hi-speed. You'd
    have to ask Intel why they developed EHCI instead of a faster OHCI,
    but that's completely unrelated to your claim. A new driver was
    needed for a new interface chip.

    > When 3200 bps USB comes out, will the same existing driver work even at the
    > new speed?


    I don't know -- was the EHCI device designed with the needed headroom?

    > Yes, there are standards for many devices on USB. But there still appear to
    > be a number of issues. Maybe manufacturers (like Seagate) just don't do USB
    > right? Why even give such leeway? Apparently there is a lack of specification
    > on disk drive spin down in USB.


    I don't know enough details on that -- it may indeed be a function not
    covered in the spec.

  16. Re: Why do not CRT/LCD monitors come with USB?

    On Sat, 26 Jul 2008 06:51:22 -0500 Harold Stevens wrote:
    | In phil-news-nospam@ipal.net:
    |
    | [Snip...]
    |
    |> Yes, there are standards for many devices on USB. But there still appear
    |> to be a number of issues.
    |
    | FWIW, I too have been very disappointed in USB over many years now. For a
    | time I thought it was typical FOSS quirks (proprietary drivers bias). But
    | over time I realized it wasn't always peachy keen outside FOSS, either.
    |
    | When I got my parents a printer for their Linux system, I ignored all USB
    | offerings. Instead, we got a great HP parallel port laser printer, for 40
    | bucks at a 2nds store. No complaints about that HP printer, years now.
    |
    | Same when they went on DSL; I was adamant with tech support that RJ45 was
    | on the modem (*NOT* USB only). When the modem arrived, I plugged the RJ45
    | jack up, and within 15 minutes had DSL running fine.

    I did this simply by telling the tech rep that I would be using a wireless
    router attached to the modem, not a computer directly attached. This got
    them past the "Windows or Mac?" question.


    | To me, USB was always a solution in search of a problem, when the problem
    | already had perfectly adequate "legacy" solutions readily evailable.
    |
    | About the only USB I do regularly now: thumbdrives for backups/xfers.

    I have a bunch of hard drives on USB. Most work rather well. One of them
    has 3 way choice (USB, eSATA, Firewire). There are hot-plug issues with the
    eSATA and I don't yet know where to point the finger of blame. With Firewire,
    the device become known to Linux a lot faster (1 or 2 seconds) than with USB
    (8 to 15 seconds). It also runs faster (40 MBps vs. 25 MBps). That's with
    USB at 480 mbps vs. Firewire at 400 mbps.

    What I would design is something to solve the broader big picture "problem"
    of getting a computer architecture closer to the KISS principle while still
    making something that works as well as modern technology allows. To me that
    means a uniform I/O bus design that is purely message based that replaces all
    I/O devices, internal or external, except the ones that _need_ to be memory
    mapped directly (the controller between CPU and uniform I/O bus would be a
    memory mapped device). Another aspect I would design in is a _fixed_ device
    path addressing. That is, any device plugged in at any location always has
    the address of that location. That would be an extendable address scheme to
    support hubs out to some finite but high number of layers. Every port could
    be physically numbered and that number used in the address. Where it is
    useful to have dynamic addresses (for example to refer to the same disk drive
    regardless where it moves to when unplugged and replugged somewhere else),
    that is a layer the OS itself should provide (and it might be names instead
    of numbers, such as the filesystem label). But the basic address is to be a
    fixed one ("1.2.3.1" meaning controller 1, port 2, port 3 on the hub plugged
    into port 2 before it, and port 1 on the next hub plugged into port 3 on the
    previou hub before it). Emulators can be plugged into these as devices to
    do things like support existing SCSI/IDE/SATA/USB/FW hard drives, but the
    goal is for this uniform I/O bus to support internal and external methods
    with clear and thorough standards for all common and semi-common devices and
    without near term programmatic limitations (e.g. allow things like disk drive
    sizes and bit rates to be very flexible and go to extremes no one can imagine
    we'd need in 50 years). A uniform interface is needed for the controllers.
    Then from there it's all message handling that the next driver layers handle
    without control for the controller (other than which one it goes to so it
    gets to the correct device). These messages can be handled in unprivileged
    processes, too (where given the specific access to the device). Every device
    that exists on the uniform I/O bus tree would have a /dev/ or other entry
    with that fixed address so a process with access rights (usually only root)
    can have direct access to the message stream when it is desired to handle
    the device directly in userspace. I would also include a way to connect two
    computers directly to each other over this kind of uniform I/O bus (then it
    has to be decided how to encapsulate IP layer packets in the messages).

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  17. Re: Why do not CRT/LCD monitors come with USB?

    On Sat, 26 Jul 2008 14:09:27 -0600 Joe Pfeiffer wrote:
    | phil-news-nospam@ipal.net writes:
    |
    |> On Thu, 24 Jul 2008 11:36:44 -0600 Joe Pfeiffer wrote:
    |>
    |> | phil-news-nospam@ipal.net writes:
    |> |>
    |> |> We need a new kind of interface. Existing ones like USB, Firewire, and SATA,
    |> |> were designed for specific purposes original and were, or will be,
    |> |> repurposed
    |> |
    |> | Ummm, USB? USB most definitely designed from the ground up to be used
    |> | for a wide variety of devices.
    |>
    |> It started as an interface to attach phones. Then it was added on to do
    |> a few computer input devices. It wasn't until USB 2.0 that speed finally
    |> became practical for things like disk storage.
    |
    | Huh? That's the first time I've ever seen anything even resembling
    | that claim. It was intended for exactly what it's good at: replacing
    | interfaces for things like keyboards, mice, and printers. Do you have
    | a cite?

    I'll look for it. I saw it only a month or so ago. A quick check of
    WIkipedia says it was designed for a few different devices apparently
    even including modems. But it is obvious disk drives were NOT intended
    at the beginning, given the slow 1.0 and 1.1 speeds.


    |> USB had to completely change the way the OS drivers worked to go to 2.0.
    |> It wasn't simply a case of being faster within the same protocol. It had
    |> to change the protocol, too. The next speed higher will require a new
    |> protocol.
    |
    | But it is just a case of being faster within the same protocol.
    | It's true that there's an extra negotiation required to go to
    | hi-speed, but once you're there it's the same protocol. I'd have to
    | spend more time than I want to to see whether the driver stack was
    | re-written at the same the EHCI driver was added.

    It should have been possible to do 400 mbps and more with OHCI, then.


    |> A better design would be an interface between driver and hardware that just
    |> goes faster when the hardware can deliver faster. The driver gives the
    |> command to send a message and in the newer faster model, the interrupt for
    |> completion of command comes back sooner. The meta registers that tell the
    |> driver what speed would have a HUGE range capacity (like a 64-bit number)
    |> beyond anyone's imagination.
    |
    | So long as the hardware can reliabily report what that speed is...

    I don't see an issue with always starting at a slow speed during the
    hardware negotiation and ramping the speed up in steps. Each time it
    steps up, each side tells the other which speeds in the next step
    range it can handle are by means of flags. These steps might be
    multiples of 2X with a few speeds in each 2X range. Once both sides
    have no more common speeds, they use the best one they both match at.
    As each new faster generation of hardware comes out, they support
    even faster speeds and do even more speed negotiation steps (but at
    the faster speeds, this go fast).

    The speed set might start at 100 mbps, require the base speed in each
    step be supported if any in that step are supported, and optionally
    allow finer speed steps such as 110, 120, 135, 150, 165, and 180.
    Then if any speed above 200 is supported, 200 must be. Each step then
    goes 200, 400, 800, 1600, 3200, 6400, 12800, 25600, 51200, and so on.

    And that's not the only way to do it. It's just one possibility.
    Another way is for the initial negotiation to state their maximum
    speed in a 32 bit number (up to 4294967295 mbps) and then they narrow
    down from there what speed they can find in common.


    |> USB also slows down substantially through hubs. It can't keep data moving
    |> along and switch it in the hub at the same time.
    |
    | I'm not aware of anything in the protocol that makes wormhole routing
    | impossible...
    |
    |> USB device addressing is flaky in design. Plug in a disk, unplug it, then
    |> plug the same disk back in to the same port, and it has a different address.
    |
    | Whether that's flaky is a matter of opinion -- the intent is that a
    | non-savvy user can unplug a disk, plug it into a different port, and
    | have the OS recognize it's the same disk. To do that, you have to
    | decouple the device addressing from the port it's plugged into; once
    | you've done that, there's no reason to treat same-port as a special
    | case.

    No you don't "have to decouple the device addressing from the port it's
    plugged into". You can remap the referenced device address or name to
    the changed physical address. This can be, and should be, done entirely
    in the OS in a layer just _above_ the core layer of device drivers.


    |> USB is not very graceful in hotplugging. It can't figure out what is going
    |> on instantly. Firewire beats USB big time, and even Firewire is poor.
    |
    | Most of that time is just allowing the device to settle.

    I see messages saying that. Maybe you can define what "settle" means.
    The only time frame I see that is needed is for repeated connections
    because the user is sloppy inserting the cable. There can be lots of
    "connecting" and "disconnecting" of the same device. Once the device
    stays connected for a fraction of a second, it should be good to go.
    It can now send its basic identify information. Extended information,
    such as how big the disk space is, can come later when the controller
    in the device gets the drive up to speed. Once that message arrives,
    then the OS can make the storage available to the storage subsystem.
    In cases of drives that know their size even before the spin up, they
    can report that immediately and the spin up can even be deferred until
    first usage.

    This "waiting for device to settle" is one of the silliest things I have
    seen in USB drivers.


    |> |> for other things. That's really not very good design. Something that is
    |> |> designed to allow _any_ kind of devide from the outset, with _standard_
    |> |> protocols included for a large variety of device uses (only ONE driver is
    |> |> needed for any one class of device, regardless of manufacturer or
    |> |> model),
    |> |
    |> | A compliant USB device of a particular class can be used with a
    |> | generic driver. The device may implement additional functionality
    |> | which requires a special driver, but core functionality can be
    |> | accessed without it (yes, I know Windows tends to not realize this.
    |> | That's not a weakness in USB).
    |>
    |> So why does the old OHCI driver not "just work" at faster speeds when a faster
    |> USB port is used with a faster device? Why are there different drivers.
    |
    | Because the old OHCI (and UHCI) devices didn't talk hi-speed. You'd
    | have to ask Intel why they developed EHCI instead of a faster OHCI,
    | but that's completely unrelated to your claim. A new driver was
    | needed for a new interface chip.

    What do you mean by "didn't talk hi-speed". Just talk faster.

    The fault here is that Intel designed OHCI (and even EHCI) in such a way that
    the speed is integral to the protocol. I would not have designed it that way
    at all. The way I would have designed it is there would be interrupts from
    the controller whenever state changes occur. If the message gets to the device
    faster in newer hardware, then its just less time between when the message is
    sent and when the next message can be sent (aside from message queueing which
    would really allow some finite but reasonably large queue of tagged messages).
    The hardware would negotiate the point-to-point link speed. It can then be
    reported to the software in sufficiently large fields to allow a huge range
    of possibilities. And the basic need for the software to know the speed is
    to report it in logging and such. Some finite subset of speeds would make
    sense for the actual hardware interfaces. This can be defined in terms of
    a set of speeds and "all multiples of X thereafter".


    |> When 3200 bps USB comes out, will the same existing driver work even at the
    |> new speed?
    |
    | I don't know -- was the EHCI device designed with the needed headroom?

    I have no idea.


    |> Yes, there are standards for many devices on USB. But there still appear to
    |> be a number of issues. Maybe manufacturers (like Seagate) just don't do USB
    |> right? Why even give such leeway? Apparently there is a lack of specification
    |> on disk drive spin down in USB.
    |
    | I don't know enough details on that -- it may indeed be a function not
    | covered in the spec.

    Then that would certainly be a deficit of the design. That's something I would
    have known to include at least 2 decades ago.

    I can understand why there are full size and mini connectors. I would not have
    done the A-type and B-type connectors. I would have used a hermaphroditic
    connector design, at least for the larger one (at about the same size as the
    USB type B). That means a connector could plug into an instance of itself and
    mate the pins correctly, both data and power. Every cord would be symmetric.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  18. Re: Why do not CRT/LCD monitors come with USB?

    phil-news-nospam@ipal.net writes:

    > On Sat, 26 Jul 2008 14:09:27 -0600 Joe Pfeiffer wrote:
    > | phil-news-nospam@ipal.net writes:
    > |
    > | Whether that's flaky is a matter of opinion -- the intent is that a
    > | non-savvy user can unplug a disk, plug it into a different port, and
    > | have the OS recognize it's the same disk. To do that, you have to
    > | decouple the device addressing from the port it's plugged into; once
    > | you've done that, there's no reason to treat same-port as a special
    > | case.
    >
    > No you don't "have to decouple the device addressing from the port it's
    > plugged into". You can remap the referenced device address or name to
    > the changed physical address. This can be, and should be, done entirely
    > in the OS in a layer just _above_ the core layer of device drivers.


    You're just decoupling in a different layer than USB is. I don't see
    any particular advantage to either approach.
    >
    > |> USB is not very graceful in hotplugging. It can't figure out what is going
    > |> on instantly. Firewire beats USB big time, and even Firewire is poor.
    > |
    > | Most of that time is just allowing the device to settle.
    >
    > I see messages saying that. Maybe you can define what "settle" means.
    > The only time frame I see that is needed is for repeated connections
    > because the user is sloppy inserting the cable. There can be lots of
    > "connecting" and "disconnecting" of the same device. Once the device
    > stays connected for a fraction of a second, it should be good to go.
    > It can now send its basic identify information. Extended information,
    > such as how big the disk space is, can come later when the controller
    > in the device gets the drive up to speed. Once that message arrives,
    > then the OS can make the storage available to the storage subsystem.
    > In cases of drives that know their size even before the spin up, they
    > can report that immediately and the spin up can even be deferred until
    > first usage.


    It's an issue of borderline-compliant devices. In this case, "settle"
    means "finish booting so it is indeed able to identify itself"

    > | Because the old OHCI (and UHCI) devices didn't talk hi-speed. You'd
    > | have to ask Intel why they developed EHCI instead of a faster OHCI,
    > | but that's completely unrelated to your claim. A new driver was
    > | needed for a new interface chip.
    >
    > What do you mean by "didn't talk hi-speed". Just talk faster.


    Not if the chip doesn't talk that fast.

    > The fault here is that Intel designed OHCI (and even EHCI) in such a way that
    > the speed is integral to the protocol. I would not have designed it that way
    > at all. The way I would have designed it is there would be interrupts from
    > the controller whenever state changes occur. If the message gets to the device
    > faster in newer hardware, then its just less time between when the message is
    > sent and when the next message can be sent (aside from message queueing which
    > would really allow some finite but reasonably large queue of tagged messages).
    > The hardware would negotiate the point-to-point link speed. It can then be
    > reported to the software in sufficiently large fields to allow a huge range
    > of possibilities. And the basic need for the software to know the speed is
    > to report it in logging and such. Some finite subset of speeds would make
    > sense for the actual hardware interfaces. This can be defined in terms of
    > a set of speeds and "all multiples of X thereafter".


    Would you mind explaining just how the protocol is different at higher
    speeds, once the negotiation is complete?

  19. Re: Why do not CRT/LCD monitors come with USB?

    On Sun, 27 Jul 2008 20:20:00 UTC in comp.os.linux.hardware,
    phil-news-nospam@ipal.net wrote:

    > With Firewire,
    > the device become known to Linux a lot faster (1 or 2 seconds) than with USB
    > (8 to 15 seconds). It also runs faster (40 MBps vs. 25 MBps). That's with
    > USB at 480 mbps vs. Firewire at 400 mbps.


    Does it actually run faster? I have a Seagate external drive here attached by
    firewire and Linux is great with it (as long as I set the allow_restart option
    in /sys/class/scsi_disk directory) but performance sucks:

    [root ~]# hdparm -tT /dev/sda

    /dev/sda:
    Timing cached reads: 2016 MB in 2.00 seconds = 1007.81 MB/sec
    Timing buffered disk reads: 68 MB in 3.02 seconds = 22.55 MB/sec

    For a 2007/8 model drive that looks like 2003 performance numbers. Then on the
    same machine I have a 2004 IDE drive in a USB case and this says

    [root ~]# hdparm -tT /dev/sdb

    /dev/sdb:
    Timing cached reads: 1920 MB in 2.00 seconds = 959.45 MB/sec
    Timing buffered disk reads: 82 MB in 3.04 seconds = 26.94 MB/sec

    If I use the "Faster but buggy" serialize_io=0 option then the transfer rate on
    firewire goes up to 23.3MB/sec and for only an extra 0.8MB/sec speed I'll stick
    with "Slower but not so buggy" option

    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2