DRM kernel module for unichrome ?

2006-03-20 Thread bruno schwander
Hi everybody,

I am trying to get DRI to work on a VIA C3 motherboard.
Background: running mplayer freezes X. (just X, I can ssh and reboot the
box)
Running mplayer -vo x11  (instead of the default that uses Xv extension)
works, but uses much CPU.
I understand that for Xv, XVmc to work, DRI must be enabled. However,
although the port graphics/dri includes a unichrome_dri.so, I do not see
the corresponding drm kernel module in /boot/loader. (I would assume it
would be unichrome.ko)

The question is then, is anybody working on this module ? How hard is it
to port the linux one over to FreeBSD ? Who owns the current drm
kernel modules and how can I assist in porting the unichrome drm module ?

bruno
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


sysctl kern.ipc.shm* description ?

2003-08-14 Thread bruno schwander
Is there a good explanation of what those variables are and the
dangers/advantages of changing them ?

I ask because I determined one port (multimedia/nuppelvideo) needs more
shared memory to run (on my system). But when I changed some of the
kern.ipc.shm* sysctl, the program ran for 15 sec and then the system froze
and rebooted after a couple seconds.

bruno

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


trying to create a port of gnotime

2003-01-15 Thread bruno schwander
Hi all,

I am trying to make a port of gnotime
( http://sourceforge.net/projects/gttr/ )

and I am hitting a few problems.
I checked how other GNOME ports work and think I used all the right
flags. When I try to build, I get the following output (appended)

I have other gnome apps that build fine. The listed dependencies for
gnotime (according to their readme) are libgnome and libgnomeui, so I
installed that first.

BTW, is it correct to list those in the LIB_DEPENDS flag ? I found no
USE_GNOME label corresponding to these libs.

If anybody with some experience building gnome apps can spot what is wrong
here, I'd be grateful for the help...

bruno


root@duron:/usr/ports/finance/gnotimemake
===  Extracting for gnotime-2.1.5_1
 Checksum OK for gnotime-2.1.5.tar.gz.
===   gnotime-2.1.5_1 depends on executable: libtool - found
===   gnotime-2.1.5_1 depends on shared library: guile.10 - found
===   gnotime-2.1.5_1 depends on shared library: gnomeui - found
===   gnotime-2.1.5_1 depends on shared library: X11.6 - found
===   gnotime-2.1.5_1 depends on shared library: esd.2 - found
===   gnotime-2.1.5_1 depends on shared library: ghttp.1 - found
===   gnotime-2.1.5_1 depends on shared library: glib12.3 - found
===   gnotime-2.1.5_1 depends on shared library: gtk12.2 - found
===   gnotime-2.1.5_1 depends on shared library: xml.5 - found
===   gnotime-2.1.5_1 depends on shared library: gdk_pixbuf.2 - found
===   gnotime-2.1.5_1 depends on shared library: Imlib.5 - found
===   gnotime-2.1.5_1 depends on shared library: ORBit.2 - found
===   gnotime-2.1.5_1 depends on shared library: gnome.5 - found
===   gnotime-2.1.5_1 depends on shared library: gnomecanvaspixbuf.1 -
found
===   gnotime-2.1.5_1 depends on shared library: oaf.0 - found
===   gnotime-2.1.5_1 depends on shared library: gconf-1.1 - found
===   gnotime-2.1.5_1 depends on shared library: capplet.5 - found
===   gnotime-2.1.5_1 depends on shared library: gnomeprint.16 - found
===   gnotime-2.1.5_1 depends on shared library: bonobo.2 - found
===   gnotime-2.1.5_1 depends on shared library: gda-client.0 - found
===   gnotime-2.1.5_1 depends on shared library: gnomedb.0 - found
===   gnotime-2.1.5_1 depends on shared library: glade.4 - found
===   gnotime-2.1.5_1 depends on shared library: gal.21 - found
===   gnotime-2.1.5_1 depends on shared library: glibwww.1 - found
===   gnotime-2.1.5_1 depends on shared library: gtkhtml-1.1.3 - found
===  Patching for gnotime-2.1.5_1
===  Configuring for gnotime-2.1.5_1
configure: WARNING: you should use --build, --host, --target
checking for a BSD-compatible install... /usr/bin/install -c -o root -g
wheel
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal-1.4... missing
checking for working autoconf... found
checking for working automake-1.4... missing
checking for working autoheader... found
checking for working makeinfo... found
checking for perl... /usr/bin/perl
checking whether to enable maintainer-specific portions of Makefiles... no
checking for i386-portbld-freebsd4.6-gcc... cc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ANSI C... none needed
checking for strerror in -lcposix... no
checking for i386-portbld-freebsd4.6-g++... c++
checking whether we are using the GNU C++ compiler... yes
checking whether c++ accepts -g... yes
checking for i386-portbld-freebsd4.6-gcc... (cached) cc
checking whether we are using the GNU C compiler... (cached) yes
checking whether cc accepts -g... (cached) yes
checking for cc option to accept ANSI C... (cached) none needed
checking how to run the C preprocessor... cc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for bison... bison -y
checking for a BSD-compatible install... /usr/bin/install -c -o root -g
wheel
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking what warning flags to pass to the C compiler... 
checking what language compliance flags to pass to the C compiler... 
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for Guile... yes
checking for pkg-config... /usr/local/bin/pkg-config
checking for libgnome-2.0 = 2.0.0 libgnomeui-2.0 = 2.0.3... yes
checking GNOTIME_CFLAGS... -DORBIT2=1 -D_REENTRANT -D_THREAD_SAFE
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
-I/usr/local/include/orbit-2.0 -I/usr/local/include/libbonobo-2.0
-I/usr/local/include/linc-1.0 -I/usr/local/include/bonobo-activation-2.0

Re: trying to create a port of gnotime

2003-01-15 Thread bruno schwander
SOLVED!

turns out I had a (I suppose obsolete ) directory
/usr/X11R6/include/gdk-pixbuf that was conflicing with
/usr/X11R6/include/gtk-2.0/gdk-pixbuf/

port coming along fine now... submitting soon

bruno

On Wed, 15 Jan 2003, bruno schwander wrote:

 Hi all,
 
 I am trying to make a port of gnotime
 ( http://sourceforge.net/projects/gttr/ )
 
 and I am hitting a few problems.
 I checked how other GNOME ports work and think I used all the right
 flags. When I try to build, I get the following output (appended)
 
 I have other gnome apps that build fine. The listed dependencies for
 gnotime (according to their readme) are libgnome and libgnomeui, so I
 installed that first.
 
 BTW, is it correct to list those in the LIB_DEPENDS flag ? I found no
 USE_GNOME label corresponding to these libs.
 
 If anybody with some experience building gnome apps can spot what is wrong
 here, I'd be grateful for the help...
 
 bruno
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



starting a program on a given ttyv

2002-08-21 Thread bruno schwander

How can I remotely start a program on the console ?

I need to remotely launch a fullscreen graphical program, without being
logged at the physical console, and redirect the input of the program so I
can feed it data (keystrokes) through the network.

any suggestions ?



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: termios guru ?

2002-07-11 Thread bruno schwander

thanks, I see the idea but cfmakeraw has some other effects... newlines
output by the program are not translated, etc.

My main program now is the VMIN/VTIME stuff. The way irit tries to use is,
is basically to be able to do async stdin reading, but this does not
work. Whenever I try those settings, no input is ever read by the
program. It fgetc() constantly returns -1.

Any idea why ?

bruno

On Thu, 11 Jul 2002, Cyrille Lefevre wrote:

 On Wed, Jul 10, 2002 at 09:13:18PM -0700, bruno schwander wrote:
  I making a port (not much really) of Irit
  (http://www.cs.technion.ac.il/~irit/) a modelling environment.
  
  I am having some problems with terminal handling, so all termios guru out
  there, please help ! :-)
  
  At stratup, irit does the following
  
  Termio.c_cc[VEOF] = 0;  /* MIN = 0, no minimal length to wait for. */
  Termio.c_cc[VEOL] = 1;  /* TIME - 1 tenth of a second as time o
  
  which seems wrong, I think it should be
  
  Termio.c_cc[VMIN] = 0;  /* MIN = 0, no minimal length to wait for. */
  Termio.c_cc[VTIME] = 1;  /* TIME - 1 tenth of a second as time o
 
 VMIN == VEOF and VTIME == VEOL.
 
  then later:
  
  Termio.c_lflag = ~ICANON;
 
 take a look at cfmakeraw(3) which is BSD specific, but that's
 not important since it's a port *to* BSD :)
 
 more +/cfmakeraw /usr/src/lib/libc/gen/termios.c
 
 cfmakeraw(t)
 struct termios *t;
 {
 
 t-c_iflag = 
~(IMAXBEL|IXOFF|INPCK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON|IGNPAR);
 t-c_iflag |= IGNBRK;
 t-c_oflag = ~OPOST;
 t-c_lflag = 
~(ECHO|ECHOE|ECHOK|ECHONL|ICANON|ISIG|IEXTEN|NOFLSH|TOSTOP|PENDIN);
 t-c_cflag = ~(CSIZE|PARENB);
 t-c_cflag |= CS8|CREAD;
 t-c_cc[VMIN] = 1;
 t-c_cc[VTIME] = 0;
 }
 
 so, a short answer could be, as Bernd Walter suggested :
 
 int
 settty(raw)
   int raw;
 {
   static int init;
   static struct termios old;
 struct termios buf, *new;
 
   if (!init) {
   if (tcgetattr(STDIN_FILENO, old)  0) {
   printf(tcgetattr failed: %s\n, strerror(errno));
   return(1);
   }
   init++;
   }
   if (raw) {
   if (init  2) {
   cfmakeraw(buf);
   init++;
   }
   new = buf;
   } else
   new = old;
 if (tcsetattr(STDIN_FILENO, TCSAFLUSH, new)  0) {
 printf(tcsetattr failed: %s\n, strerror(errno));
 return(1);
 }   
   return(0);
 }
 
 Cyrille.
 -- 
 Cyrille Lefevre mailto:[EMAIL PROTECTED]
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



termios guru ?

2002-07-10 Thread bruno schwander

I making a port (not much really) of Irit
(http://www.cs.technion.ac.il/~irit/) a modelling environment.

I am having some problems with terminal handling, so all termios guru out
there, please help ! :-)

At stratup, irit does the following

Termio.c_cc[VEOF] = 0;  /* MIN = 0, no minimal length to wait for. */
Termio.c_cc[VEOL] = 1;  /* TIME - 1 tenth of a second as time o

which seems wrong, I think it should be

Termio.c_cc[VMIN] = 0;  /* MIN = 0, no minimal length to wait for. */
Termio.c_cc[VTIME] = 1;  /* TIME - 1 tenth of a second as time o

then later:

Termio.c_lflag = ~ICANON;

basically, irit wants to manage line editing itself, to manage the irit
command prompt. There is some code doing the ^A, ^H, etc handling and line
printing, and reading periodically stdin.

What I see happening, is that usually at the very beginning, input seems
locked. Running in the debugger, I see that characters are fgetc'ed
periodically, but fgetc always returns -1 even when there should be
characters available.

I then tried using fcntl(0, F_SETFL, O_NONBLOCK) instead of the above 2
lines. which I thought would do the right thing, ie: non blocking IO, but
anything available from stdin is buffered and provided on the next read.
This works, however I am seeing something strange on stdout now: when
outputting lots of lines, outputs stalls after a few dozen lines. Adding a
usleep between each fwrite() solves the problem but slows it all
down... (and is inherently wrong)

What is going on here ? I do not understand very well all the terminal/IO
discipline here.

I agree that this is all bad design, and should probably multithread or
use select() but I am not Irit's author...

bruno


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: examining the environment

2001-03-13 Thread bruno schwander

Thanks everybody,

I checked the code and the magic function is

kvm_getenvv()


bruno

Wes Peters wrote:

 bruno schwander wrote:
 
  Hi everybody,
 
  How can I examine an other process environment ?
 
  I have a daemon that needs to do something according to an environment
  variable set in a different process. Can I open an other process and lookup
  environment variables set in his space ?

 ps can do this, check it's code.

 --
Where am I, and what am I doing in this handbasket?

 Wes Peters [EMAIL PROTECTED]

--

###

Bruno Schwander
Senior Software Engineer

Worldgate Communications, Inc

email: [EMAIL PROTECTED]






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: close call in a device ?

2000-11-08 Thread bruno schwander

Hello,

Luigi Rizzo wrote:

 you could do something like this:
 + open allocates a descriptor which stores the PID of the process requesting
   access to the "device"


doing that now

 + each I/O operation uses the descriptor matching the PID passed to the
   read/write/ioctl

that too


 + you could implement an ioctl() to dispose the storage, a "well behaved"
   process would have to invoke this ioctl before terminating;

I could, but my problem is that the process is not under my control. I can't modify
the program to have it do something more. Maybe I can have a module that captures the
close call and make it issue my special cleanup ioctl ? Or maybe that call won't be
intercepted precisely because of the so far observed behavior ?
back to studying the kernel module stuff


 + and a timeout as you suggested could be used to purge entries that have
   been idle for some time, or you could also purge them basing on usage
   patterns assumning there are clearly identifiable ones.


yes, but that is the problem again, there may not be clearly identifiable patterns. At
least, in the worst case, I could just check the process table and when a process goes
away, I clean its associated resources. And I have to hope that a given process does
not reopen and close the device several times.


  Did I miss something in your suggestion ? Or were you suggesting that I can
  create same name device entries, differing only by their minor number ? But then

 you cannot use the same name unless the entries are in different
 directories. My suggestion was to use /dev/foo.00 /dev/foo.01 /dev/foo.02
 and so on.


yep, I tried and tested that now :-)

well there may not be a simple solution, but I think the idea of trapping "close"
calls may work if I can trap the actual call before the kernel does its job of
deciding where to route the call (which driver) and if the driver "close" should be
called. Thanks for the idea.

Any comments anyone ?

bruno

#######

Bruno Schwander
Senior Software Engineer

Worldgate Communications, Inc
email: [EMAIL PROTECTED]







To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: close call in a device ?

2000-11-08 Thread bruno schwander

Terry Lambert wrote:

   when a process closes the device, I do not get a "close" call for each
   process closing the device. I instead get a close only on the last
   process closing the device.
 
  devices in a similar way as the one is used for scanning pty's).

 To add to this, the close calls can be forces; there is a flag
 in the device structure wich can force notification.  I'm not
 sure what it does over a fork(), though: I think you really want
 open notification.


You mean that when I register my device/kernel module, I can explicitely
request that all close calls will notify my module ? That is exactly what I
need.
What do you mean by open notification ? I do get all "open" calls to my
device, just not all the "close"

 The main problem with per process resources is that the VFS that
 implements devices, specfs, doesn't own its own vnodes.

Could you develop a little ? I don't know about VFS, specfs and vnodes...

What I did is make a module that defines a struct cdevsw with the open/read/
etc callbacks, then I register my calls for various devices entries with
make_dev(), and at the end used the DEV_MODULE() macro to declare it to the
system. I modeled that after the example in /usr/src/share/examples/kld of
FreeBSD 4

Is there a different driver/module architecture ?


 This is actually the primary reason that VMWARE can only run
 one instance at a time of a virtual machine: there is no way
 to have per open instance resources, which are not shared.

 If you were to use the TFS flag (grep for TFS in the headers,
 that's a substring), you could make specfs own its own vnodes.


Where should I look for this ? I looked into /usr/src/ and only some
references to NTFS and TFS filesystems turned up ?

Would I have to roll out a custom filesystem to have this running ?


 The way you would handle your problem then is by returning a
 different instance of the device, with a different instance of
 per process attached storage.  It's pretty simple to do this:
 just return a different vnode for the next open of the same
 device, instead of the same vnode with an additional reference.

this is really confusing me... in the example I had, the only thing I return
from my open routine is an int telling success or errors happened... any
pointers for the vnode stuff ? if it could apply to what I am trying to do ?

Am I basing my driver on the wrong stuff ?

 NB: If you are trying to do this for VMWARE or some other binary
 code, there's no way that the pty opening soloution suggested in
 the previous posting will be able to work for you, since the code

Yes, I came to that conclusion too.

 will expect a particular behaviour.  Right now, FreeBSD doesn't
 support this behaviour (cloning devices), but as pointed out
 above, it's not hard to implement, it's mostly just labor
 intensive.

 Terry Lambert
 [EMAIL PROTECTED]
 ---
 Any opinions in this posting are my own and not those of my present
 or previous employers.

--

#######

Bruno Schwander
Senior Software Engineer

Worldgate Communications, Inc
email: [EMAIL PROTECTED]







To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: close call in a device ?

2000-11-08 Thread bruno schwander

Julian Elischer wrote:

 the problem here can be solved by using Poul's 'cloning device'
 interface in the driver.
 I don't think he has it quite completed but it is partly there.. maybe
 enough..


this seems very promising. Any pointers toward more info on this ?

Thanks

bruno



 only in -current at the moment and you need to have devfs turned on.

 each time you open it, you actually get a different device and  vnode..
 
  Terry Lambert
  [EMAIL PROTECTED]
  ---
  Any opinions in this posting are my own and not those of my present
  or previous employers.
 
  To Unsubscribe: send mail to [EMAIL PROTECTED]
  with "unsubscribe freebsd-hackers" in the body of the message

 --
   __--_|\  Julian Elischer
  /   \ [EMAIL PROTECTED]
 (   OZ) World tour 2000
 --- X_.---._/  presently in:  Budapest
 v

--

###

    Bruno Schwander
Senior Software Engineer

Worldgate Communications, Inc
tel:(408) 378-7800 x116
fax:   (408) 378-8018
email: [EMAIL PROTECTED]







To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



close call in a device ?

2000-11-07 Thread bruno schwander

Hello everybody,

I am writing a pseudo-device driver (as a kernel module) that needs to
be opened in write mode by several processes. The problem I am having is
that I do get all the "open" calls when a process opens the device, and
I am able to process data written, etc. on a per-process basis; however,
when a process closes the device, I do not get a "close" call for each
process closing the device. I instead get a close only on the last
process closing the device.

This is a problem since I need to allocate/free resources for each
process accessing the device, at the time a process closes the device.

Is there a way to make sure my driver gets all "close" calls ?

I could possibly get around this by using timeouts, but the
unpredictability of the accessing processes may make this very difficult
and suboptimal, so getting the "close" calls would be way better

Thank you all for any information on this

bruno

--

#######

Bruno Schwander
Senior Software Engineer

Worldgate Communications, Inc
email: [EMAIL PROTECTED]







To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: close call in a device ?

2000-11-07 Thread bruno schwander

Hi,

The reason I am doing this, is precisely because I need to virtualize accesses
from several processes to _one_  _predefined_ device. I have no control over that
device name from the client process point of view, so I can not have multiple
devices.  I pretty much need to be able to lie to the process, telling it that it
has full control of the device it wants, and actually allow other processes to
open and use the device in the same way at the same time.

Did I miss something in your suggestion ? Or were you suggesting that I can
create same name device entries, differing only by their minor number ? But then
I still hit the problem that the processes are maybe not going to open the device
in exclusive mode ?


 the reason for this is that you might have a process fork() after
 it has opened the device, and you do not want to get to the
 device all close calls from all processes generated by the original
 one, but really only the last instance.

 The thing is, i think your model (allocating per-user resources on
 open) is wrong. It cannot protect you from a process forking
 and then having two instances using the same device.


I can walk the process tree to figure whose parent process allocated the resource
and thus use the same resource for the child, so this is not a problem (I
think...). Besides, in my context, I doubt the process will fork after opening
the device.

 If you want multiple instances of the device, one option could be
 to use the minor number and really create multiple instances
 of the device, and open them in exclusive way so you know that
 there can be only one open per device (you should scan available
 devices in a similar way as the one is used for scanning pty's).

 cheers
 luigi



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message