Re: Getting data from the ATAPI-CD driver
Soren Schmidt wrote: snippertysnip 2) Using VOP_STRATEGY on the acd device in audiofs_strategy(), the way the cd9660 filesystem does it. I'm not sure this will work, but it sure looks like it. This would also reduce code complexity, but I'm not sure it's 'right' either. What would be the 'right' way? 2. -Søren Thanks, got it to work. I'm going to clean up my code, then test it some more and release it sometime this week. -- Theo van Klaveren [EMAIL PROTECTED] http://home.student.utwente.nl/t.vanklaveren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: audiofs mixing audio and data tracks
Soren Schmidt wrote: | Ahem, maybe its time I chime in here. | Luigi and I once had an idea of having each track on a CD represented | by a device node, ie track0 = /dev/acd0t1 track1 = /dev/acd0t2 etc etc, | that way you could mount each track with whatever fs it supported. | This could be used to do what you want, and now where the ata driver | supports odd sector sizes, there is nothing hindering doing the | mount of an audio track (given the right mount_bla util that is). I stand corrected. I hadn't thought the ATA driver was so close to doing that already. Then again, I haven't extensively studied the ATA code yet. | The only problem is that we have to abuse the minor# etc to | get space for the 99 tracks a CD can hold, but that is not too bad... Tracks, as in audio tracks? You wouldn't want a device for each audio track, you want one device for _all_ audio tracks and one device per data track. Or am I misunderstanding you here? Theo van Klaveren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: audiofs mixing audio and data tracks
Soren Schmidt wrote: | Well, the idea is that you get one device pr CD track, that way you can | do what you want with them, ie to rip audio track 4 you do: | | dd if=/dev/acdNt4 of=track4.raw bs=2352 | | To mount data track5 with an ISO filesys: | | mount -t cd9660 /dev/acdNt5 /cdrom | | If you want to collect all audio tracks together you would just | use the normal /dev/acd0c device, read the TOC of the CD so | you know where they are, set the right blocksize, and there | you go (that works now BTW). Ah, okay, that's great, but that's what audiofs already does (or will do with that function of yours), so I'll just go on hacking now :-) Theo van Klaveren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
In-kernel ioctl calls
I think I've finally figured out why AudioFS isn't working (aside from an endianess error in v0.1), but I can't think of a solution. The problem I've found is as follows: The code in atapi-cd.c (from Soren's ATA driver) assumes the passed buffer (in the ioctl struct) is in user-space. The following is the offending piece of code from the CDIOCREADAUDIO ioctl call: --- snip --- if ((error = atapi_queue_cmd(cdp-atp, ccb, buffer, size, ATPR_F_READ, 30, NULL,NULL))) break; if ((error = copyout(buffer, ubuf, size))) break; --- snip --- The first statement issues the read command to the device, I presume. It copies the data to an internal (kernel-space) buffer. Next, the internal buffer is copyout()ed to ubuf (which is my ioctl buffer), which fails because in the case of AudioFS it's in kernel space. Boing, break, abort, no data for you. Bad boy. This, of course, caused the buffer's data not to be initialized, causing noise and crackles. And AudioFS didn't know the ioctl call failed, because the driver didn't return an error. Am I just doing it wrong, or should atapi-cd.c be patched to verify if the buffer is in user space or in kernel space? If so, what function checks if an address is in kernel space or in user space? If not, what am I doing wrong? Theo van Klaveren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: In-kernel ioctl calls
Soren Schmidt wrote: -long story snipped- | Am I just doing it wrong, or should atapi-cd.c be patched to verify if the | buffer is in user space or in kernel space? If so, what function checks if | an address is in kernel space or in user space? If not, what am I doing | wrong? | | Here's another idea, the ata driver can read/write 2352 sector size | blocks directly, no need to use that ugly ioctl. You just have to | set the right blocksize, I could provide you with a function for | that, no more ioctl mess ;) That would be _greatly_ appreciated! The question is, would this be 'portable' to other drivers? In other words, how much trouble would it cost me to get AudioFS to work with SCSI? (On a side note, I'll be getting a SCSI card and accompanying Plextor CDROM from a friend of mine soon, so I can work at getting AudioFS to work on SCSI CDROMs). Theo van Klaveren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: audiofs mixing audio and data tracks
Koster, K.J. wrote: | Could you perhaps make it so that all the audio tracks appear als slice 1, | while the data track appears as slice 2. Sorry if I come across rude, but I've had numerous requests for this and just wanted to say what I think about it. I can't think of any way of accomplishing this without either: 1) Combining the code for AudioFS and CD9660, as both require access to the mounted device, and hacking them to respect each other, or 2) Hacking the ATAPI-CD and SCSI-CD drivers to bits and teaching them about the various regions on the CD. Neither are very attractive, IMHO, and I don't think the trouble is worth it by far. But if anyone knows a clean, un-hackish way to accomplish double-mounting a multi-track CD, please make yourself heard. Otherwise, I declare this subject closed. Theo van Klaveren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
AudioFS for -CURRENT
I've patched AudioFS to compile on -CURRENT. Untested, though. http://www.xs4all.nl/~havoc/audiofs-current-0.1.tar.gz MD5 (audiofs-current-0.1.tar.gz) = b864657f44741507097f90bea6c98a37 Greetings, Theo van Klaveren [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ANNOUNCEMENT: Test version of AudioFS
After many late nights of caffeine, pizza and debugging, I'm glad to announce a test-version of the Audio Filesystem for FreeBSD. AudioFS is a virtual filesystem that allows you to access audio tracks on your CDROM drive as though they were ordinary .WAV files. This lets you, for example, to encode your MP3's straight from the CD. Note that this is UNSTABLE code, and should not be used if you value your data, diskdrive or bank account. Also note that there are still some (minor) issues with the code; they are mentioned in the TODO file inside the tarball. Please read it before you do anything at all. Most noteable of these is that I have not tested the audio-extraction routine because the CDROM at my current location doesn't support digital audio extraction. I've tested a replacement routine which fills a buffer with zero's, and everything seemed fine, so I'm confident 'the real thing' will work as well (famous last words). It should compile (and work) on 4.1-RELEASE. It's untested on CURRENT. Included in the tarball is the source for the module and a hacked-up mount_cd9660(8) and required sources from mount(8) for the mounting. Grab your bits at: http://www.xs4all.nl/~havoc/audiofs-0.1.tar.gz (12824 bytes) MD5 (audiofs-0.1.tar.gz) = 3eb324903d1ce4387397d2878c4b51f1 Installation procedure: $ tar xvzf audiofs-0.1.tar.gz ... $ cd audiofs $ make depend make all ... $ su # cp audiofs/audiofs.ko /modules # cp mount_audiofs/mount_audiofs /sbin After which you can just mount your CDROM with 'mount -t audiofs /dev/acd0c /cdrom'. If you're scared of the debug output (it's a lot, i know), you can turn it off by commenting out '-DDEBUG' from the Makefiles. Please note that this is my first attempt at kernel code, so go gently on me :) Comments, panics, backtraces, style(9)-nailing and (preferably) patches are welcome. Please reply to [EMAIL PROTECTED] or this mailing list, I'm using a temporary address (I'm not at home :) Theo van Klaveren [EMAIL PROTECTED] Powered by FreeBSD and two cups of strong coffee. --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Compiler error while compiling XFree86-3.9.17
I received the following compiler error while compiling the XFree86-3.9.17
snapshot on a (very) fresh -CURRENT system:
-- begin cut'n'paste --
cc -c -O2 -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wredundant-decls -Wnested-externs -I. -I.-I../../../include/fonts -I../mi
-I../../../programs/Xserver/hw/xfree86/common -I../../../include/fonts
-I../../.. -I../../../exports/include -DCSRG_BASED -DSHAPE -DXKB -DLBX
-DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV
-DPANORAMIX -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH
-DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE
-DX_BYTE_ORDER=X_LITTLE_ENDIAN -DSMART_SCHEDULE -DNDEBUG -DFUNCPROTO=15
-DNARROWPROTO xf86vmode.c
In file included from xf86vmode.c:41:
../include/extnsionst.h:91: warning: function declaration isn't a
prototype
../include/extnsionst.h:100: warning: function declaration isn't a
prototype
../include/extnsionst.h:106: warning: function declaration isn't a
prototype
xf86vmode.c: In function `ProcXF86VidModeGetMonitor':
xf86vmode.c:1320: Unable to generate reloads for:
(insn 300 298 302 (parallel[
(set (reg:SI 0 %eax)
(fix:SI (fix:SF (subreg:SF (reg:SI 0 %eax) 0
(clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
(const_int -34 [0xffde])) 0))
(clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
(const_int -36 [0xffdc])) 0))
(clobber (mem:SI (plus:SI (reg:SI 6 %ebp)
(const_int -40 [0xffd8])) 0))
(clobber (scratch:HI))
] ) 145 {fix_truncsfsi2+1} (insn_list 293 (nil))
(expr_list:REG_DEAD (reg:SI 0 %eax)
(expr_list:REG_UNUSED (scratch:HI)
(nil
*** Error code 1
Stop in /usr/home/havoc/Build/xc/programs/Xserver/Xext.
-- end cut'n'paste --
I assume this is a compiler bug. Is there a workaround or a patch
available for the system compiler or should I install the gcc-devel port
(for which I probably don't have enough disk space, but oh well)?
/^\ | Theo van Klaveren [EMAIL PROTECTED]
/^\\_//^\ | http://phoenix.student.utwente.nl ICQ #1353681
\_/-|-\_/ |
/ | This email was powered by FreeBSD
`He's the mad scientist, and I'm his beautiful daughter.'
- opening sentence from Heinlein's 'The number of the beast'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about GLIDE...
On Thu, 23 Dec 1999, Doug Rabson wrote: I already ported the voodoo2 sources for Glide 2.x and Glide 3.x. You can find patches at: http://www.freebsd.org/~dfr/Glide-V2-2.53.diff http://www.freebsd.org/~dfr/Glide-V2-3.01.diff Actually, I was talking about the Voodoo Graphics sources. Sorry for not mentioning that. Theo van Klaveren [EMAIL PROTECTED] http://phoenix.student.utwente.nl / ICQ #1353681 - Why, oh why didn't I take the _blue_ pill? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about GLIDE...u
On Thu, 23 Dec 1999, Doug Rabson wrote: On Thu, 23 Dec 1999, Andrew Kenneth Milton wrote: +[ Doug Rabson ]- | On Wed, 22 Dec 1999, Theo van Klaveren wrote: | | I already ported the voodoo2 sources for Glide 2.x and Glide 3.x. You can | find patches at: | | http://www.freebsd.org/~dfr/Glide-V2-2.53.diff | http://www.freebsd.org/~dfr/Glide-V2-3.01.diff I have an old Voodo Graphics card, I've seen people talking about V2 and V3, is that because the Voodoo 1 is not going to work, or because noone else has crappy hardware like me? d8) If it's not going to work, I guess I can bite the bullet and get a V3. I don't have a v1. I'm sure it would work pretty easily though. I have a Voodoo 1 (and a very limited budget, too :), and the I'm porting the source you're talking about. I'll clean it up and release it as a patch as soon as I'm finished. Won't be working on it during the holidays, though. Theo van Klaveren [EMAIL PROTECTED] http://phoenix.student.utwente.nl / ICQ #1353681 - Why, oh why didn't I take the _blue_ pill? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about GLIDE...
On Thu, 23 Dec 1999, Doug Rabson wrote: I added it to the -current build a couple of weeks ago when I was working on Glide. Hadn't seen it :) Thanks! Theo van Klaveren [EMAIL PROTECTED] http://phoenix.student.utwente.nl / ICQ #1353681 - Why, oh why didn't I take the _blue_ pill? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
GLIDE for FreeBSD
Whew. After two late nights of furious hacking, you can now download the modified source for Glide 2.46 (the Voodoo Graphics version) at ftp://phoenix.student.utwente.nl/pub/glide Note: I have completely hacked the source to bits to achieve this. The source has been autoconf'ed (scary, but at least it works, which cannot be said of the build system 3DFX provided). All source files needed for FreeBSD compilation have been included, but Windows-compilation etc. have been dropped. I'd be more than happy to accept patches which'll make it compile on other platforms again, but chances are you'll have to get the neccesary files from the original source file. Also, binaries of GLIDE and Mesa+glide are available for FreeBSD-CURRENT. The GLIDE library has one bug, though: When quitting an application, it won't restore the normal display. If anyone can help me with this, that'd be GREAT! One last question: What are the chances of incorporating the sources for Voodoo2/3 into one source tree? They all have the swlibs/ directory (almost unchanged)... Theo van Klaveren [EMAIL PROTECTED] http://phoenix.student.utwente.nl / ICQ #1353681 - Why, oh why didn't I take the _blue_ pill? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Question about GLIDE...
Hello,
I am in the process of porting the GLIDE library to FreeBSD/i386
which is making good progress so far. My worst enemy has been the
build system itself and the huge amount if `#ifdef __linux__' in
the code.
I am doing this in the light of the Quake source code
release, which I'd like to play natively with 3dFX hardware... :)
(for the interested: I have already gotten the server and X11
client to build, but I haven't tested them yet.)
My question is about this particular piece of code in
swlibs/fxpci/pcilib/fxlinux.c, around line 70:
if (iopl(3)0) {
pciErrorCode = PCI_ERR_NO_IO_PERM;
return FXFALSE;
}
Does anyone know what 'iopl(3)' is supposed to do,
and what it's equivalent on FreeBSD is (if at
all available)?
The code this is in is about opening the /dev/3dfx device
(which is not available for FreeBSD so it'll fail anyway),
so I _could_ just remove it, but I'm not so certain...
Also, IANAL, so could anyone tell me if the 3DFX license
permits me to publish my patches under a BSD-style license?
Theo van Klaveren [EMAIL PROTECTED]
http://phoenix.student.utwente.nl / ICQ #1353681
- Why, oh why didn't I take the _blue_ pill?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
