On Thu, Jul 21, 2011 at 04:24:11PM -0500, Frank Zerangue wrote:
The examples you site seem to indicate that for example the le device may
attach to many
alternative devices (e.g. pci, tc, …), but only one attachment is made when
autoconf is complete. I may have
read the code examples
On Thu, Jul 21, 2011 at 05:42:59PM -0500, David Young wrote:
I think you mean to ask if one device instance can have more than one
parent, e.g.,
le0 at pci0
le0 at pci1
or
le0 at pci0
le0 at isapnp0
I am pretty sure that is not possible.
I'm
On Fri 22 Jul 2011 at 06:26:56 +0200, gilbert.fernan...@orange.fr wrote:
Broke my Thinkpad X30 keyboard while being in Germany.
Found in a shop a brand new keyboard, told it was
German. Turns out it's not German, it's Dutch.
That must be very rare! Nobody in their right mind uses a Dutch
The test fcntl_getlock_pids() from fs/vfs/t_vnops.c assumes
fcntl(fd, F_GETLK, lock) returns the blocking lock with the
lowest start offset.
Our documentation and POSIX.1 document it returning the
first lock that blocks but doesn't call for any specific order.
Should I fix fcntl() to return the
J. Hannken-Illjes wrote:
The test fcntl_getlock_pids() from fs/vfs/t_vnops.c assumes
fcntl(fd, F_GETLK, lock) returns the blocking lock with the
lowest start offset.
Our documentation and POSIX.1 document it returning the
first lock that blocks but doesn't call for any specific order.
I
On Fri, Jul 22, 2011 at 11:13:48AM +0100, Alexander Nasonov wrote:
J. Hannken-Illjes wrote:
The test fcntl_getlock_pids() from fs/vfs/t_vnops.c assumes
fcntl(fd, F_GETLK, lock) returns the blocking lock with the
lowest start offset.
Our documentation and POSIX.1 document it returning
On Jul 22, 2011, at 12:13 PM, Alexander Nasonov wrote:
J. Hannken-Illjes wrote:
The test fcntl_getlock_pids() from fs/vfs/t_vnops.c assumes
fcntl(fd, F_GETLK, lock) returns the blocking lock with the
lowest start offset.
Our documentation and POSIX.1 document it returning the
first lock
Hello all,
could I obtain information if udl driver support X11 for Displaylink
devices 1x0/1x5? I am planning to by perhaps UGA-2K-A and I would like
to be sure if it works under X11.
Thank you very much.
With kind regards.
Piotr.
J. Hannken-Illjes wrote:
As any program relying on a special order is not portable I would suggest to
either remove this test or change it as appended testing overlap only.
If noone objects I will commit this change during the weekend.
I would wait until we get a clarification from
On Fri, Jul 22, 2011 at 03:04:42PM +0200, Piotr Adamus wrote:
Hello all,
could I obtain information if udl driver support X11 for Displaylink
devices 1x0/1x5? I am planning to by perhaps UGA-2K-A and I would like
to be sure if it works under X11.
Should work via xf86-video-wsfb.
jakllsch wrote:
On Fri, Jul 22, 2011 at 03:04:42PM +0200, Piotr Adamus wrote:
Hello all,
could I obtain information if udl driver support X11 for Displaylink
devices 1x0/1x5? I am planning to by perhaps UGA-2K-A and I would like
to be sure if it works under X11.
Should work via
On Fri, Jul 22, 2011 at 10:59:37AM +0200, Rhialto wrote:
That must be very rare! Nobody in their right mind uses a Dutch
keyboard. And I say that as a Dutch person.
They are. I know the Dutch have moved to using the US international
keyboard and are no longer using this one. But that was the
Hello,
thanks. That's pity- I think I saw xorg.conf under Linux with both
options for Intel or Nvidia driver plus udl (they use framebuffer I
believe). Let me test it (two three weeks).
KR.
Piotr.
On Fri, Jul 22, 2011 at 10:18 PM, Michael macallan1...@gmail.com wrote:
Hello,
On Fri, 22 Jul
I have a hardware configuration with a cmos camera sensor on an i2c bus (for
configuring the camera) and connected to an (ipu) image processing controller
that acts as a hub for all things video. I envisioned (naturally I think) a
camera driver inheriting from two parents 1) i2c bus driver and
On Fri, 22 Jul 2011, Frank Zerangue wrote:
I have a hardware configuration with a cmos camera sensor on an i2c bus (for
configuring the camera) and connected to an (ipu) image processing controller
that acts as a hub for all things video. I envisioned (naturally I think) a
camera driver
J. Hannken-Illjes wrote:
As any program relying on a special order is not portable I would suggest to
either remove this test or change it as appended testing overlap only.
I've changed the test to find all locks regardless of an internal
ordering of locks in the kernel. The test passes now.
16 matches
Mail list logo
