Stelian Pop announced a new driver for the Sony Vaio MotionEye camera from the Picturebook models. He posted a patch and explained:
The driver does not yet support overlay (no docs... :-( ), but it does support grabbing, jpeg snapshots and mjpeg compressed videos (through a private API, documented in <file:Documentation/video4linux/meye.txt>).
Until the alcove-labs web site updates, you can download the 'motioneye' application documented in meye.txt from: http://mapage.noos.fr/pop/sonypi and http://mapage.noos.fr/pop/meye
Alan Cox asked if the hardware really supported overlay, and Stelian
confirmed that it did, though he added, even if I know
how to program the mchip to output to the video bus, there is something missing
to enable overlay (either in the mchip or in the ati video driver).
Alan
speculated:
It could be using the YUV digital inputs to the ATI chip. It seems however also quite likely to me that windows is doing the following
- Issuing USB transfers which put the data into video ram overlay buffers (ie the DMA from the USB controller)
- Using the YUV overlay/expand hardware in the ATI card (see http://www.linuxvideo.org/gatos for X stuff for ATI for this)
Stelian agreed, but also said that after a quick look at the Gatos site,
it seems that the Rage Mobility P/M card which this
laptop has isn't yet supported.
Linus Torvalds replied:
It definitely is - at least if you use the XFree86 CVS tree with just the ATI video extensions imported from Gatos. I've used the YUV hardware for half-accelerated DVD playing ("half-accelerated" only because the chip can really do MC too, but ATI doesn't document how to do it, so it only does the YUV conversion).
I've not figured out why the ATI Xv stuff from gatos seems to not have made it into the XFree86 CVS tree - it works better than much of the Xv stuff for some other chipsets that _are_ in the CVS tree.
I imported it into the XFree86 CVS some months ago, it was trivial. I don't have the patches lying around any more, though. I can try to re-create them if anybody needs help.
After a bit more discussion Stelian said, the
main question remains: does the MotionEye camera support overlay or not
? It could be that it is connected to the feature connector of the ATI
board for doing direct video input/output (but no X driver recognizes this
connector today). The motion jpeg chip this camera is based on definately
has a video output. Or it could just be the application who gets YUV data
from the chip then send it directly to the video board. Today this works,
almost (because we need a patched X - read gatos - and a patched xawtv -
in order to do scaling).
Linus replied that he had no idea about
overlay support, and the thread ended inconclusively.
Shawn Starr asked about the status of Intel gigabit Ethernet NIC (copper)
with the TL82543GC chipset under Linux. He said, The
sales guy who is promoting it says this is apparently a new card and he claims
he can get specs from engineering.
Alan Cox burst into loud peals of
laughter. As these subsided, he replied, Nobody has been
able to get remotely useful docs out of intel on their 1Gbit ethernet.
Riley Williams suggested, tell the said sales
guy that IF he can get you the FULL specs TOGETHER WITH permission to freely
distribute them, AND "a friend of yours who knows how to read such specs"
confirms that they are indeed FULL specs, then you'll consider buying some
of the cards, but if not, you're not interested...
Ion Badulescu
pointed out that permission to distribute the specs was not strictly
necessary, as long as it was possible to distribute driver sources under
the GPL. Ralf Baechle argued, You then have a
GPL'ed driver which still cannot be sanely modified in the way the GPL would
like to guarantee.
But James Sutherland replied, the GPL doesn't attempt to guarantee users the INFORMATION needed
to make sane changes, just that they have the facility to do so. Just as
the kernel doesn't come with a copy of the POSIX specs, the RFCs, etc. -
some of the standards the kernel implements aren't available publicly, but
that doesn't stop the kernel being freely modifiable!
At one point
Alan reiterated, you have a better chance of getting
a straight answer out of a politician than intels networking folks.
At one point Shawn gave an update on his interaction with Intel, saying,
No word yet. I would be extremely surprised to get
the docs WITHOUT an NDA or so. It never hurts to try though :-)
Brent D. Norris asked about the status of the 3Com Etherlink 10/100 PCI
NIC with 3XP processor under Linux; in particular Brent had heard that the
card handled DES encryption without using the CPU. He asked if Linux took
advantage of that, and Kip Macy replied, It can't
because 3com hasn't implemented in the driver and they won't publish the
interface.
Brent replied that his impression had been that 3com was
fairly friendly to the Linux community. He asked if that was a misconception,
and Kip said, they are relatively friendly. However, if
they publish the interface to their card another company could come along with
a card with the same functionality and take advantage of pre-existing drivers
and undercut their price, thus taking away their margins. At least that is the
rationale I have been given and this has occurred on at least one occasion
to Adaptec.
Alan Cox replied, Crypto hardware
is commodity. In fact its questionable it has any value below 1Gbit/second
anyway because the cheapest low speed crypto coprocessors are made by AMD
and intel. They fit into the second socket on your dual cpu motherboard and
as well as being mass market are conveinently reprogrammable and able to run
your applications when not doing crypto. The cheapest raid accelerator is
the same story. It costs a lot of money to build custom hardwae, an x86 is
the wrong solution but its sufficiently large a hamemr that it works better
than the elegant approach for most cases.
At one point Martin Moerman from 3Com said, To
make it easier, Tell me exactly what you need in documentation and I will
try to get it for you.
There was no reply.
Larry McVoy reported reproducible data corruption under 2.4.5, and Eugene
Crosser also reported, These days I observed
massive FS curruption on vanilla 2.4.5, SCSI disk on Sym53c8-something
controller (UW). I did not notice any problems since 2.4.5 was published, they
seem to have surfaced immediately after I created a rather big file capturing
video with broadcast2000 (video card is bt848). Filesystem is ext2.
Alan Cox confirmed this problem. Later Larry reported that his corruption
was not as reproducible as he'd first thought, and the thread petered out.
Linus Torvalds announce 2.4.6-pre3 and explained:
User-noticeable things: if you are tired of not being able to NFS-export your reiserfs tree, this should make you happy.
VM tuning has also happened, with Rik van Riel, Mike Galbraith, Marcelo Tosatti and Andrew Morton all doing various tweaks. Give it a whirl.
He also posted the changelog:
pre3:
- remember to increment the version number
- Chris Mason: reiserfs mark_journal_new and bh leak fix
- Richard Gooch: devfs update
- Alexander Viro: further FS cleanup (superblock list)
- David Woodhouse: MTD update
- Kai Germaschewski: ISDN update (stanford checker fixes etc)
- Rich Baum: gcc-3.0 warning fixes
- Jeff Garzik: network driver updates
- Geert Uytterhoeven: m68k fbdev logo merge glitch fix
- Andrea Arcangeli: fix signal return path
- David Miller: Sparc updates
- Johannes Erdfelt: USB update
- Carsten Otte, Andries Brouwer: don't clear blk_size unconditionally on partition check
- Martin Frey: alpha Sable irq fix
- Paul Mackerras: PPC softirq update
- Patrick Mochel: PCI power management infrastructure
- Robert Siemer: miroSOUND driver update
- Neil Brown: knfsd updates, including ability to export ReiserFS filesystems
- Trond Myklebust: NFS readdir fixup, don't update atime on client
- Andrew Morton: truncate_inode_pages speedup
- Paul Menage: make inode quota count all inodes..
Keith Owens replied to item 8, reporting compiler warnings from the tulip
driver. Jeff Garzik replied, There are no network
driver updates, including no tulip updates. The PCI API changed, there is
breakage and cleanup is needed
Tim Waugh said with a frown, ..in a stable kernel series.. :-((
At one point Linus
said:
It shouldn't have broken anything. The warning happens, but the function call ends up doing the same thing as it used to - old drivers will just ignore the new argument.
It was a necessary step in working ACPI suspend. Which Patrick has working - with caveats. And the fact that Pat happens to work at the same company I do probably has more to do with the fact that Transmeta is obviously interested in suspend issues more than most - and not so much with the fact that he would exert undue influence on me.
Andrea Arcangeli reported:
There are a number of changes in kernel API visisble to userspace that are unregistered in 2.4 mainline. I recommend to merge them ASAP to avoid generating collisions across different versions of the kernel.
I'll attach here a number of patches that should make us to return in sync. They must be applied incrementally. (really the very last one is mostly here for comments, not intendeted for merging in mainline)
here the first that defines O_DIRECT (NOTE: the O_DIRECT value for alpha is not definitive yet, O_DIRECTIO of tru64 is our O_NOFOLLOW so we're just screwed as we just need a wrapper anyways to make complex programs like dbms to run correctly without having to natively port them to linux, 02000000 in tru64 is O_DSYNC, maybe I should move it to 010000000 instead which maybe unused in tru64, but still we would have no guarantee that it won't be used in the future, I was waiting Richard's comment about it).
The sparc64 values are approved by Dave.
Dan Streetman from IBM said:
IBM Retail Store Solutions dept has certain PS/2 keyboards which extend the standard PS/2 specification in order to support addition hardware built into the keyboard (such as a Magnetic Strip Reader, Keylock, Tone generator, extra keys, extra LEDs, etc). This addition hardware behaves in a manner that makes it unusable if driven by a standard PS/2 driver (sadly, due to the fact that its design is "IP" I can't elaborate on how or why it is incompatible with the standard PS/2 specification).
In order to use these keyboards, a the standard PS/2 driver needs to behave a bit differently; thus attached is a modifcation to the PS/2 driver which allows other drivers to register with the PS/2 driver as 'filters'. There is a arbitrary max number of 'filters' set to 1, which is a compile-time define. The registered drivers are called (in order of registration) for every scancode, and they may change or consume the scancode (or allow it to pass). Also the 'filters' are given a function to send an variable-sized buffer to the keyboard output port; this function is synchronized using a semaphore which also coordinates with pckbd_leds().
Jeff Garzik asked, Didn't we just conclude a
discussion here on linux-kernel, which said that patches which simply add
hooks allowing proprietary extensions are not accepted into the kernel?
Andries Brouwer replied, There is a certain need
for this kind of patches. I have seen similar stuff for the blind, or for
disabled people who for example can use only one hand. Also for people who
use a combined keyboard/barcode reader. Hooks for drivers that do something
special have other uses than for proprietary extensions.
Elsewhere,
Michael Rothwell added:
I'm facing a similar problem with the "Qoder" barcode scanner. I have to have a keyboard hook. The "right" way seem to be to use the input api. Unfortunately, this means that current kernels can't use the driver w/o a patch (the input api patch). The ugly way is to patch the keyboard driver. I'm doing both.
However, I wrote a REALLY SIMPLE hook tht supported exactly my needs, since it's in the category of "ugly hack waiting for input api." Maybe I'll write a version for your hook.
I wonder when the input api stuff for ps/2 devices will be a part of the mainstream kernel...
Dan himself also replied to Jeff, saying:
I never intended to get that patch in. In fact I would be shocked (and a bit horrified) if it was accepted.
But management doesn't listen to me when I say it will never get accepted so I had to make a token effort of submitting it to prove it won't get accepted.
And I did try hard to convince them to release the actual driver but it didn't work.
Mike A. Harris replied:
I find it very odd indeed with IBM's big voice of open source praise, yada yada, and what Lou has said in the past, that there would be any question at all of wether it would be open source or not. Isn't big blue behind open source? Or is it just for publicity? Makes me wonder now...
Must be some real good rocket science in that interface that theres no way on earth someone else could come up with it for it to be important IP to protect. Makes me wonder what's hiding behind it...
Dan replied, I actually think that in this case
(and possibly many others) it's not a case of wanting to 'protect' amazing
code or design, but more that people are used to working a certain way
(closed), and it's hard to change. They still have a 'reflex' that tells
them to keep it closed, and need a good business (or legal) reason to open
it...instead of asking 'why not?' they ask 'why?'.
An anonymous attacker posted an email virus to linux-kernel and a bunch of folks just laughed at it.
Rusty Russell posted a link and announced, Version 0.3 (untested) of the HotPlug CPU Patch is out,
with ia64 and x86 support.
Bringing a CPU up and down, he said, was as
simple as changing the value of /proc/sys/cpu/1. Christoph Hellwig suggested
using /proc/sys/cpu/<num>/enable instead, so that other per-cpu sysctls could be added more easily.
Rusty agreed
it would be better, but said, rewrite the sysctl
crap first to make dynamically adding and deleting entries sane.
Alexander Viro chimed in, I had, actually. 2.5
stuff, but as soon as fs/super.c merge gets into the sane area I'll see
what can be safely merged into 2.4. Sorry - it touches quite a few places
and running two splitups in parallel... <shudder> As soon as this fscking
roll of barbwire^W^W^Wset of locking changes gets untangled...
Eric S. Raymond finally snapped, and said (as they wheeled him down to his padded cell):
Various people on the Linux kernel mailing list and elsewhere have been heard to opine that CML2's user interface is too oriented towards nontechnical users. In response to these complaints, I have implemented a fourth CML2 front end with an interface style expressly designed for the serious, hard-core hacker. A transcript of an example session follows:
-------------------------------------
Welcome to CML2 Adventure, version 1.6.1.
You are in a maze of twisty little Linux kernel options menus, all different.
The main room. A sign reads `Linux Kernel Configuration System'.
Passages lead off in all directions.> n
The arch room. A sign reads `Processor type'.
A passage leads upwards.
Choose your processor architecture.
A brass lantern is here.
There is a row of buttons on the wall of this room. They read:
X86, ALPHA, SPARC32, SPARC64, MIPS32, MIPS64, PPC, M68K, ARM, SUPERH, IA64, PARISC, S390, S390X, CRIS
The button marked X86 is pressed.
> take lantern
Lantern: taken.
> look X86
Value of X86 is y.
This is Linux's home port. Linux was originally native to the Intel 386, and runs on all the later x86 processors including the Intel 486, 586, Pentiums, and various instruction-set-compatible chips by AMD, Cyrix, and others.
> up
In main room.
> nearby
The arch room. A sign reads `Processor type'.
The archihacks room. A sign reads `Architecture-specific hardware hacks'.
The buses room. A sign reads `System buses and controller types'.
The pm room. A sign reads `Power management'.
The mtd room. A sign reads `Memory Technology Device (MTD) support'.
The x86 room. A sign reads `Intel and compatible 80x86 processor options'.
The policy room. A sign reads `Configuration policy options'.
The generic room. A sign reads `Architecture-independent feature selections'.
The block_devices room. A sign reads `Block devices'.
> go generic
The generic room. A sign reads `Architecture-independent feature selections'.
A passage leads upwards.There is an option named MODULES here.
There is an option named NET here.
There is an option named SYSVIPC here.
There is an option named BSD_PROCESS_ACCT here.
There is an option named SYSCTL here.
There is an option named BINFMT_AOUT here.
There is an option named BINFMT_MISC here.
There is an option named SMP here.
> take NET
NET: taken.
> take MODULES
Tristate symbols won't default to M.
MODULES: taken.
> up
In main room.
> nearby
The arch room. A sign reads `Processor type'.
The archihacks room. A sign reads `Architecture-specific hardware hacks'.
The buses room. A sign reads `System buses and controller types'.
The pm room. A sign reads `Power management'.
The mtd room. A sign reads `Memory Technology Device (MTD) support'.
The x86 room. A sign reads `Intel and compatible 80x86 processor options'.
The policy room. A sign reads `Configuration policy options'.
The generic room. A sign reads `Architecture-independent feature selections'.
The block_devices room. A sign reads `Block devices'.
> go buses
The buses room. A sign reads `System buses and controller types'.
A passage leads upwards.
Specify the buses, disk controllers, and internal interconnection standards that you want your kernel to support.
It is very dark. If you continue, you are likely to be eaten by a grue.
There is an option named EISA here.
There is an option named PCI here.
There is an option named PNP here.
There is an option named PARPORT here.
There is an option named HOTPLUG here.
There is an option named IDE here.
There is an option named SCSI here.
There is an option named USB here.
There is an option named I2O here.
There is an option named MTD here.
There is an option named WATCHDOG here.
> light lantern
The lantern radiates a mellow golden light.
> take PCI
PCI: taken.
> help
Welcome to the adventure configurator. For a command summary, type `commands'.
In general, a three-letter abbreviation of any command word is sufficient to identify it to the parser.
This interface emulates the style of classic text adventure games such as Colossal Cave Adventure and Zork. Configuration menus are rooms, and configuration options are objects that can be taken and dropped (except for choice/radiobutton symbols, which become buttons on various room walls). Objects and rooms may silently appear and disappear as visibilities change.
Have fun, and beware of the grues!
In main room.
> commands
look [target] -- look here or at target (direction or option). nearby -- list nearby rooms (useful with go) go -- go to a named menu (follow with the label). inventory -- show which options you have picked up. drop -- unset option. take [module] -- set option, follow with option name. press -- press a button (follow with the button name). set -- set numeric or string; follow with symbol and value. load -- read in a configuration (follow with the filename). save -- save the configuration (follow with a filename). xyzzy -- toggle suppression flag. quit -- quit, discarding changes. exit -- exit, saving the configuration. You can move in compass directions n,e,w,s,ne,nw,se,sw or dn for down.
> quit
Several folks felt that Eric needed help immediately if not sooner,
and Eric later confessed, I wrote most of CML2
Adventure on a long airplane flight.
But Wayne Browne said, OK, Eric, you've finally done it. You've bypassed my
objections to CML2 and won me over. I *have* to try it now. :-)
Eric chose to blame an imaginary being named "Rick Moen" (clearly an invented
cognate of his own name, to whit: "Eric" -> "Rick", and "RayMond
-> "Moen" -- a typical childish transposition in this sort of case).
One of the doctors made the mistake of suggesting that Eric might not have
actually written the code to do this, and that the log file was merely the
fabrication of a fevered mind. But Eric said, CML2
Adventure is part of the 1.6.1 release of CML2. You can download it from http://www.tuxedo.org/~esr/cml2/
and try it out yourself.
Thus endeth the thread.
Eric S. Raymond was not the only unfortunate victim this week. David Fort
suggested from atop his Frankensteinian lair, I've
tested the User Mode Linux a few times ago, and it gave me an idea: given the
fact that we had a GCC which produce bytecode from C, it would be possible to
produce a port of linux(a new directory "jvm" in the arch dir) which would run
in a Java Virtual Machine. (after some inquiries such compiler does not exist
:-( ) I'm dreaming of a linux booting in a browser applet(imagine sending
such thing in a mail to MS peoples !!!!)
Bruce Holzrichter replied,
While I am not sure if this is possible with
Linux, something like this has already been done with Inferno. Check out: http://www.vitanuova.com/inferno/pidoc/index.html
.
And Jeff Dike added:
If you really want to help the MS peoples get Linux, consider a straight port of UML to Windows.
I've been trying to encourage someone to do this for a while, with limited success :-( Enough has been done that I think I know what the main obstacles are, and I think I know that it's possible.
So, if you're interested (and have the appropriate Win-fu) let me know, and grab the code and start porting...